From michael at dunlops.com Sun Jun 1 20:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun Jun 1 19:03:33 2003 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 07:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: Tue Jun 3 12:49:26 2003 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 09:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue Jun 3 13:38:12 2003 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 11:44:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue Jun 3 14:14:41 2003 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 11:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue Jun 3 15:14:11 2003 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 12:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue Jun 3 16:32:12 2003 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root@skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 12:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue Jun 3 16:50:13 2003 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Thu Jun 5 16:27:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu Jun 5 06:50:21 2003 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis@baesystems.com From allan at data-house.com Tue Jun 3 11:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: Sat Jun 7 03:21:30 2003 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 13:13:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat Jun 7 15:43:02 2003 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 17:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat Jun 7 16:21:09 2003 Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 18:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat Jun 7 17:44:11 2003 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 9 07:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon Jun 9 06:18:46 2003 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj@www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis@baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 15:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon Jun 9 19:26:33 2003 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 20:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon Jun 9 19:30:26 2003 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx@linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 20:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon Jun 9 19:34:42 2003 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 15:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon Jun 9 19:44:22 2003 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx@linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 15:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon Jun 9 19:45:01 2003 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Tue Jun 10 05:03:08 2003 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava@cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj@www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis@baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 09:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue Jun 10 08:16:02 2003 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava@cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj@www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 03:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed Jun 11 02:12:10 2003 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh@hp.com; LUONG, Minh-Tuan; > gojava@cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava@cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj@www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx@linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 21:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Wed Jun 11 02:14:58 2003 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj@linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh@hp.com; LUONG, Minh-Tuan; gojava@cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava@cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj@www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 22:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Wed Jun 11 04:27:15 2003 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj@linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh@hp.com; LUONG, Minh-Tuan; >gojava@cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava@cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj@linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj@www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis@baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx@linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx@linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx@linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://undine.linuxgrrls.org/pipermail/rxtx/attachments/20030610/ce055180/smime-0001.bin From taj at linuxgrrls.org Wed Jun 11 15:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed Jun 11 14:07:02 2003 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj@linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > rxtx@linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj@www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis@baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Thu Jun 12 11:59:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu Jun 12 02:29:42 2003 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj@linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > rxtx@linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj@www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis@baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Thu Jun 12 03:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu Jun 12 02:42:51 2003 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > > rxtx@linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj@www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 12 04:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu Jun 12 03:06:06 2003 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > > > rxtx@linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj@www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx@linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 15:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu Jun 12 10:57:12 2003 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://undine.linuxgrrls.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment.bin From taj at linuxgrrls.org Thu Jun 12 13:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu Jun 12 12:06:10 2003 Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis@baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 13:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu Jun 12 12:24:36 2003 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty@averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 09:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu Jun 12 13:06:19 2003 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 14:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu Jun 12 13:24:41 2003 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 09:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu Jun 12 13:42:20 2003 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 15:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu Jun 12 14:46:17 2003 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty@averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 10:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu Jun 12 16:35:40 2003 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://undine.linuxgrrls.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment.bin From taj at linuxgrrls.org Thu Jun 12 18:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu Jun 12 17:27:32 2003 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 11:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu Jun 12 17:46:10 2003 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://undine.linuxgrrls.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0001.bin From taj at linuxgrrls.org Mon Jun 16 18:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon Jun 16 17:05:08 2003 Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 20:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon Jun 16 19:11:18 2003 Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 15:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon Jun 16 19:42:39 2003 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 21:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon Jun 16 20:01:54 2003 Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 14:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon Jun 16 20:17:40 2003 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://undine.linuxgrrls.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment.bin From taj at linuxgrrls.org Mon Jun 16 21:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon Jun 16 20:54:43 2003 Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 22:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon Jun 16 21:19:17 2003 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Tue Jun 17 00:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: Tue Jun 17 04:17:46 2003 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne@Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Tue Jun 17 05:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue Jun 17 04:25:53 2003 Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne@Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Tue Jun 17 00:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Tue Jun 17 04:31:41 2003 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne@Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 23:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue Jun 17 22:58:45 2003 Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio@apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj@www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 18:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed Jun 18 17:12:33 2003 Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 09:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon Jun 23 08:01:04 2003 Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 09:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon Jun 23 08:15:27 2003 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 10:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed Jun 25 09:23:26 2003 Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root@wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj@www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 11:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed Jun 25 10:08:43 2003 Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj@www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 11:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed Jun 25 10:22:01 2003 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de taj@parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx@linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 11:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed Jun 25 10:31:09 2003 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > nome de taj@parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx@linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj@www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 21:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu Jun 26 19:30:08 2003 Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Fri Jun 27 01:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 27 00:57:36 2003 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Fri Jun 27 03:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 27 02:28:53 2003 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Fri Jun 27 03:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 27 02:49:14 2003 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Fri Jun 27 08:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri Jun 27 06:02:52 2003 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 07:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 27 06:21:58 2003 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 07:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 27 06:37:08 2003 Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 08:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 27 07:12:08 2003 Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 09:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri Jun 27 07:21:49 2003 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx@linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 08:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 27 07:31:13 2003 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx@linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx@linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 09:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri Jun 27 07:54:42 2003 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx@linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx@linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx@linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 09:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 27 08:08:17 2003 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx@linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx@linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx@linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx@linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 19:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Fri Jun 3 17:45:29 2005 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 12:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 13:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 14:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 15:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 16:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root@skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 16:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Thu Jun 5 06:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis@baesystems.com From allan at data-house.com Tue Jun 3 16:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 15:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 16:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 17:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 9 06:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj@www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis@baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 19:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 19:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx@linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 19:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:30 2005 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 19:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Fri Jun 3 17:45:31 2005 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx@linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 19:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Fri Jun 3 17:45:31 2005 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Tue Jun 10 05:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Fri Jun 3 17:45:31 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava@cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj@www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis@baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 08:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:31 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava@cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj@www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 02:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:31 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh@hp.com; LUONG, Minh-Tuan; > gojava@cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava@cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj@www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx@linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Wed Jun 11 01:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Fri Jun 3 17:45:31 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj@linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh@hp.com; LUONG, Minh-Tuan; gojava@cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava@cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj@www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Wed Jun 11 04:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Fri Jun 3 17:45:32 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj@linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh@hp.com; LUONG, Minh-Tuan; >gojava@cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava@cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj@linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj@www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis@baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx@linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx@linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx@linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20030610/ce055180/smime-0002.bin From taj at linuxgrrls.org Wed Jun 11 14:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:32 2005 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj@linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > rxtx@linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj@www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis@baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Thu Jun 12 02:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Fri Jun 3 17:45:32 2005 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj@linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > rxtx@linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj@www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis@baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Thu Jun 12 02:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:32 2005 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > > rxtx@linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj@www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 12 03:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:32 2005 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > > > rxtx@linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj@www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx@linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 21:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Fri Jun 3 17:45:33 2005 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment.pgp From taj at linuxgrrls.org Thu Jun 12 12:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:33 2005 Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis@baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 12:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:33 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty@averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 13:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 17:45:33 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 13:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:33 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 13:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 17:45:33 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 14:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:33 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty@averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 16:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Fri Jun 3 17:45:33 2005 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment.pgp From taj at linuxgrrls.org Thu Jun 12 17:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:33 2005 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 17:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Fri Jun 3 17:45:33 2005 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment.pgp From taj at linuxgrrls.org Mon Jun 16 17:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:33 2005 Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 19:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 19:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 20:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 20:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment.pgp From taj at linuxgrrls.org Mon Jun 16 20:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 21:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Tue Jun 17 04:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne@Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Tue Jun 17 04:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne@Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Tue Jun 17 04:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne@Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 22:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio@apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj@www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 17:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 08:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 08:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Fri Jun 3 17:45:34 2005 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 09:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root@wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj@www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 10:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj@www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 10:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de taj@parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx@linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 10:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > nome de taj@parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx@linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj@www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 19:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Fri Jun 27 00:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Fri Jun 27 02:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Fri Jun 27 02:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Fri Jun 27 06:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 06:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 06:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 07:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:35 2005 Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 07:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri Jun 3 17:45:36 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx@linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 07:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:36 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx@linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx@linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 07:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri Jun 3 17:45:36 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx@linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx@linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx@linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 08:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 17:45:36 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx@linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx@linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx@linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx@linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 19:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Fri Jun 3 18:07:49 2005 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 12:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 13:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 14:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 15:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 16:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root@skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 16:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Thu Jun 5 06:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis@baesystems.com From allan at data-house.com Tue Jun 3 16:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 15:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 16:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 17:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 9 06:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj@www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis@baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 19:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Fri Jun 3 18:07:50 2005 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 19:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri Jun 3 18:07:51 2005 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx@linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 19:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:51 2005 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 19:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Fri Jun 3 18:07:51 2005 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx@linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 19:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Fri Jun 3 18:07:51 2005 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Tue Jun 10 05:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Fri Jun 3 18:07:51 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava@cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj@www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis@baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 08:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:52 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava@cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj@www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 02:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:52 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh@hp.com; LUONG, Minh-Tuan; > gojava@cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava@cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj@www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx@linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Wed Jun 11 01:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Fri Jun 3 18:07:52 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj@linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh@hp.com; LUONG, Minh-Tuan; gojava@cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava@cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj@www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Wed Jun 11 04:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Fri Jun 3 18:07:53 2005 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj@linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh@hp.com; LUONG, Minh-Tuan; >gojava@cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava@cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj@linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj@www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis@baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx@linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx@linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx@linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20030610/ce055180/smime-0003.bin From taj at linuxgrrls.org Wed Jun 11 14:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:53 2005 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj@linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > rxtx@linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj@www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis@baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Thu Jun 12 02:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Fri Jun 3 18:07:53 2005 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj@linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > rxtx@linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj@www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis@baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Thu Jun 12 02:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:53 2005 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > > rxtx@linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj@www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 12 03:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:54 2005 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh@hp.com; catherine_guiollot@hp.com; > > > rxtx@linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj@www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis@baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx@linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 21:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Fri Jun 3 18:07:54 2005 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0001.pgp From taj at linuxgrrls.org Thu Jun 12 12:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:54 2005 Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis@baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 12:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:54 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty@averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 13:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 18:07:54 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 13:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:54 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 13:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Fri Jun 3 18:07:54 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 14:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:54 2005 Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty@averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 16:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Fri Jun 3 18:07:54 2005 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0001.pgp From taj at linuxgrrls.org Thu Jun 12 17:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:54 2005 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 17:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Fri Jun 3 18:07:55 2005 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0001.pgp From taj at linuxgrrls.org Mon Jun 16 17:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:55 2005 Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 19:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:55 2005 Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 19:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Fri Jun 3 18:07:55 2005 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj@linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx@linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 20:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:55 2005 Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 20:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Fri Jun 3 18:07:55 2005 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0001.pgp From taj at linuxgrrls.org Mon Jun 16 20:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:55 2005 Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 21:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:55 2005 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Tue Jun 17 04:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: Fri Jun 3 18:07:55 2005 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne@Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Tue Jun 17 04:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:55 2005 Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne@Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Tue Jun 17 04:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Fri Jun 3 18:07:55 2005 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne@Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx@linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 22:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio@apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj@www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 17:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 08:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 08:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 09:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root@wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj@www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 10:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj@www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 10:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de taj@parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx@linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 10:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > nome de taj@parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx@linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj@www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 19:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Fri Jun 27 00:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Fri Jun 27 02:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Fri Jun 27 02:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Fri Jun 27 06:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri Jun 3 18:07:56 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 06:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:57 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 06:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:57 2005 Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 07:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:57 2005 Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 07:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri Jun 3 18:07:57 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx@linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 07:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:57 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx@linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx@linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 07:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri Jun 3 18:07:57 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx@linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx@linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx@linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 08:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri Jun 3 18:07:57 2005 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx@linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx@linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx@linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx@linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0396.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0396.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0396.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0396.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0395.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0397.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0397.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0397.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0397.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0396.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0398.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0398.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0398.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0398.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0397.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0399.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0399.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0399.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0399.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0398.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0400.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0400.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0400.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0400.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0399.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0401.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0401.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0401.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0401.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0400.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0402.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0402.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0402.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0402.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0401.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0403.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0403.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0403.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0403.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0402.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0404.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0404.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0404.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0404.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0403.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0405.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0405.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0405.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0405.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0404.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0001.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0001.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0001.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0001.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0001.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0002.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0002.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0002.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0002.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0002.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0003.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0003.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0003.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0003.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0003.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0004.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0004.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0004.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0004.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0004.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0005.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0005.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0005.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0005.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0005.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0006.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0006.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0006.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0006.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0006.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0007.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0007.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0007.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0007.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0007.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0008.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0008.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0008.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0008.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0008.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0009.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0009.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0009.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0009.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0009.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0010.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0010.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0010.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0010.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0010.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 01:16:01 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 10 Jun 2003 08:16:01 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <041101c32f05$1287fdb0$c35ef40f@am710222> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> <041101c32f05$1287fdb0$c35ef40f@am710222> Message-ID: Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Tue Jun 10 19:12:09 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 02:12:09 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: Hi Awais Understood. I'm not aware of Chris's status with respect to communications with support. Perhaps thats his best path. What I'd think would be good to have happen is we put whatever fix if the problem is able to reproduced out from rxtx.org We could do a rxtx 2.0 release and merge the fixes I've got in rxtx 2.1. We have done extensive testing with 2.1. It would be a good time to consider a new 2.0 release from our end. Almost all of the fixes apply to w32 though. There has been little thats needed to change for Solaris/Linux. That makes the race a little perplexing. We run a fairly complete test suite on Solaris and Linux. I understand you probably have your own requirments for doing releases/testing but we can get something out from rxtx.org with little hassle. I'm just trying to make it as easy as possible to get a possible fix out. Would that sound reasonable? If you give me a days notice I'll put all the fixes from 2.1 into the 2.0 cvs. If you wanted to do a release also, it would be a good time to. The next coding I was intending to do is deal with the known problems but thats going to take another round of QA before its as stable as what we have now. I put a list of known problems on the top of http://www.rxtx.org which you can evaluate and decide what would be best. I trust we will wait until we hear more from Chris. If there is anything else I can do to help, just let me know. On Tue, 10 Jun 2003, SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: > Hello Trent, > > > I trust HP will either look at this or offer ssh access to a box > > to figure out what is going on given the gift the rxtx group > > gave HP with regards to licensing. > Let me say it very emphatically, expecting/asking for an > ssh connection to HPUX box through us is not possible. As > I mentioned yesterday, the right channel for such kind > of support is: BAESystems should contact their HP support > contact. Has Chris tried that? > > Your support and cooperation regarding licensing > issues was with mutual understanding and you did what was > justified and fair. > > Please also understand, JavaComm is available along with sources > for reference only. HP has no commitment of support. > > However, I can try to spare some time and look at it, > but only if I could get a testcase. > I cannot make any time commitment. > > I would also like to know. What is expected: > * Another JavaComm release? > * Investigate the problem and share the fix with RXTX? > * Anything else? > > Regards, > Awais > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Tuesday, June 10, 2003 12:16 AM > To: Java RXTX discussion > Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; > gojava at cup.hp.com > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Awais, > > Cathrine left HP for her day job: art. I've removed her from the cc list. > Lucky gal :) > > Chris clearly demonstarated with -Xeprof that the eventLoop() function is > spinning out of control. I'm not sure why. Maybe the sleep() is breaking > out or the select() is not doing what is expected due to pending data. > > I can only guess at what is going on from here as I've just done. > > I trust HP will either look at this or offer ssh access to a box to figure > out what is going on given the gift the rxtx group gave HP with regards > to licensing. > > On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > Hello Chris/Trent, > > We are not actively involved with activities on RXTX and it's > > mailing list. To get quick response from HP, It's important > > to send requests through your HP support contact. For > > issues related to HP Java Runtime or Java Tools, one may also > > consider sending email addressing gojava at cup.hp.com > > > > Sometime about a year back we invested some effort > > to make RXTX based native library to work on HPUX. It was > > based on 2.0.5. It available for reference only. For all latest > > updates http://www.rxtx.org is the source. > > > > Please also read statement of support for the Comm API at URL > > http://www.hp.com/products1/unix/java/com_api/support/index.html > > > > I am not sure where/what could be the problem. Is it possible > > you could provide us any test case. If not can you please try > > running your application using option -Xeprof. This should > > generate an output file. Can we get that eprof file. > > > > You may not have to but, you might also wanna consider viewing > > this eprof file using HPjmeter (performance analysis tool ) > > accessible from: > > http://www.hpjmeter.com > > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > > > Regards, > > Awais > > > > > > ----- Original Message ----- > > From: "Trent Jarvi" > > To: "AVIS, Chris" > > Cc: ; ; "LUONG, Minh-Tuan" > > ; > > Sent: Sunday, June 08, 2003 10:18 PM > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and > hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should > now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try > to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad > things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've > also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license > issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box > to > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API > which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at > 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and > the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. > We > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour > as > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From awais.sheikh at hp.com Tue Jun 10 18:15:25 2003 From: awais.sheikh at hp.com (SHEIKH,AWAIS (HP-Cupertino,ex1)) Date: Tue, 10 Jun 2003 20:15:25 -0400 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Hello Trent, > I trust HP will either look at this or offer ssh access to a box > to figure out what is going on given the gift the rxtx group > gave HP with regards to licensing. Let me say it very emphatically, expecting/asking for an ssh connection to HPUX box through us is not possible. As I mentioned yesterday, the right channel for such kind of support is: BAESystems should contact their HP support contact. Has Chris tried that? Your support and cooperation regarding licensing issues was with mutual understanding and you did what was justified and fair. Please also understand, JavaComm is available along with sources for reference only. HP has no commitment of support. However, I can try to spare some time and look at it, but only if I could get a testcase. I cannot make any time commitment. I would also like to know. What is expected: * Another JavaComm release? * Investigate the problem and share the fix with RXTX? * Anything else? Regards, Awais -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Tuesday, June 10, 2003 12:16 AM To: Java RXTX discussion Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; gojava at cup.hp.com Subject: Re: [Rxtx] HPUX 100% CPU Utilisation Hi Awais, Cathrine left HP for her day job: art. I've removed her from the cc list. Lucky gal :) Chris clearly demonstarated with -Xeprof that the eventLoop() function is spinning out of control. I'm not sure why. Maybe the sleep() is breaking out or the select() is not doing what is expected due to pending data. I can only guess at what is going on from here as I've just done. I trust HP will either look at this or offer ssh access to a box to figure out what is going on given the gift the rxtx group gave HP with regards to licensing. On Mon, 9 Jun 2003, Awais Sheikh wrote: > Hello Chris/Trent, > We are not actively involved with activities on RXTX and it's > mailing list. To get quick response from HP, It's important > to send requests through your HP support contact. For > issues related to HP Java Runtime or Java Tools, one may also > consider sending email addressing gojava at cup.hp.com > > Sometime about a year back we invested some effort > to make RXTX based native library to work on HPUX. It was > based on 2.0.5. It available for reference only. For all latest > updates http://www.rxtx.org is the source. > > Please also read statement of support for the Comm API at URL > http://www.hp.com/products1/unix/java/com_api/support/index.html > > I am not sure where/what could be the problem. Is it possible > you could provide us any test case. If not can you please try > running your application using option -Xeprof. This should > generate an output file. Can we get that eprof file. > > You may not have to but, you might also wanna consider viewing > this eprof file using HPjmeter (performance analysis tool ) > accessible from: > http://www.hpjmeter.com > http://www.hp.com/products1/unix/java/hpjmeter/index.html > > Regards, > Awais > > > ----- Original Message ----- > From: "Trent Jarvi" > To: "AVIS, Chris" > Cc: ; ; "LUONG, Minh-Tuan" > ; > Sent: Sunday, June 08, 2003 10:18 PM > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From nehring at newparticles.com Tue Jun 10 21:27:03 2003 From: nehring at newparticles.com (L Nehring) Date: Tue, 10 Jun 2003 21:27:03 -0600 Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> References: <123E41AA62E54346A34828E6646156731932FB@xsun03.ptp.hp.com> Message-ID: <3EE6A187.2040006@newparticles.com> Sounds like Awais is wanting to steer a wide path clear of this unsupported LGPL stuff. ;-)) I would search HP's IT resource center for the latest patch bundles for your HP box and see if you are in need patches. Even patches that fix things unrelated to the problem can end up being what you need. A couple years back I had HP support help with some patch analysis for an entire weekend for a project being deployed into production. What had worked perfectly fine in development dumped core in production. I finally spotted a missing curses patch (of all things....I wasn't really using curses, but needed a symbol out of the library...) that was causing the trouble with my heavy network surveillence application. If your company has a paid support contract you get more features when using the support site (and better access to patches). If you're the system administrator you'll be familiar with this site - I've used it quite a bit in the past: http://us-support.external.hp.com/common/bin/doc.pl Also, (maybe you already did this) the website where you download the HP build Java 1.4 lists the various patches specifically for the HP Java port that you'll want to make sure are installed: http://www.hp.com/products1/unix/java/infolibrary/patches.html There's also a tuning tool that changes kernel parameters for better Java performance. In any event, if you want HP to help, you'll need to start a support request as Awais mentioned - they will want to know your exact patch level and exact environment, plus a program to demonstrate the problem, before they can really do anything. There's probably information on the support site about this.....it been awhile since I've surfed through it..... I have some Agilent contacts, but I'm not sure if I can get sufficient access to an HP box to help out. It's too bad SourceForge doesn't have one in their server farm. I don't know if the HP Porting Center can help any: http://hpux.cs.utah.edu/ They have lots of ported GPL/LGPL software. I've never corresponded with them - just download their ported software..... Best of luck, Lance Nehring New Particles Corporation Disclaimer: I'm not an HP employee - and speak with no authority at all - but I have worked with some of their boxes over the past few years and thought I'd give some suggestions. SHEIKH,AWAIS (HP-Cupertino,ex1) wrote: >Hello Trent, > > > >>I trust HP will either look at this or offer ssh access to a box >>to figure out what is going on given the gift the rxtx group >>gave HP with regards to licensing. >> >> >Let me say it very emphatically, expecting/asking for an >ssh connection to HPUX box through us is not possible. As >I mentioned yesterday, the right channel for such kind >of support is: BAESystems should contact their HP support >contact. Has Chris tried that? > >Your support and cooperation regarding licensing >issues was with mutual understanding and you did what was >justified and fair. > >Please also understand, JavaComm is available along with sources >for reference only. HP has no commitment of support. > >However, I can try to spare some time and look at it, >but only if I could get a testcase. >I cannot make any time commitment. > >I would also like to know. What is expected: >* Another JavaComm release? >* Investigate the problem and share the fix with RXTX? >* Anything else? > >Regards, >Awais > > >-----Original Message----- >From: Trent Jarvi [mailto:taj at linuxgrrls.org] >Sent: Tuesday, June 10, 2003 12:16 AM >To: Java RXTX discussion >Cc: AVIS, Chris; awais.sheikh at hp.com; LUONG, Minh-Tuan; >gojava at cup.hp.com >Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > >Hi Awais, > >Cathrine left HP for her day job: art. I've removed her from the cc list. >Lucky gal :) > >Chris clearly demonstarated with -Xeprof that the eventLoop() function is >spinning out of control. I'm not sure why. Maybe the sleep() is breaking >out or the select() is not doing what is expected due to pending data. > >I can only guess at what is going on from here as I've just done. > >I trust HP will either look at this or offer ssh access to a box to figure >out what is going on given the gift the rxtx group gave HP with regards >to licensing. > >On Mon, 9 Jun 2003, Awais Sheikh wrote: > > > >>Hello Chris/Trent, >>We are not actively involved with activities on RXTX and it's >>mailing list. To get quick response from HP, It's important >>to send requests through your HP support contact. For >>issues related to HP Java Runtime or Java Tools, one may also >>consider sending email addressing gojava at cup.hp.com >> >>Sometime about a year back we invested some effort >>to make RXTX based native library to work on HPUX. It was >>based on 2.0.5. It available for reference only. For all latest >>updates http://www.rxtx.org is the source. >> >>Please also read statement of support for the Comm API at URL >>http://www.hp.com/products1/unix/java/com_api/support/index.html >> >>I am not sure where/what could be the problem. Is it possible >>you could provide us any test case. If not can you please try >>running your application using option -Xeprof. This should >>generate an output file. Can we get that eprof file. >> >>You may not have to but, you might also wanna consider viewing >>this eprof file using HPjmeter (performance analysis tool ) >>accessible from: >>http://www.hpjmeter.com >>http://www.hp.com/products1/unix/java/hpjmeter/index.html >> >>Regards, >>Awais >> >> >>----- Original Message ----- >>From: "Trent Jarvi" >>To: "AVIS, Chris" >>Cc: ; ; "LUONG, Minh-Tuan" >>; >>Sent: Sunday, June 08, 2003 10:18 PM >>Subject: RE: [Rxtx] HPUX 100% CPU Utilisation >> >> >> >> >>>Hi Chris, >>> >>>Let's hope we can get ssh access to a box. HP owes rxtx big time for >>>making a LGPL modification for them in rxtx 2.0 free of charge and >>> >>> >hassle. > > >>>Don't be afraid to remind them of that. I could have forced them to pay >>>for an HP box at the time but just did the right thing as they should >>> >>> >now. > > >>>It is not easy to know whats going on. The one thing I may suggest is >>>replacing the usleep with a sleep. The eventLoop should be fairly >>>intuitive without digging into the called functions below it. Just try >>> >>> >to > > >>>put the brakes on it with some sleeps. If you go beyond 10 ms bad >>> >>> >things > > >>>will start to happen but 1 ms should make the problem all but go away. >>> >>>Maybe that select() is not doing what I expect? Are you sitting with >>>unread data? >>> >>>If this is really critical you could always use a pc and tcp/ip to >>>get the data where it needs to go... >>> >>>I've cc'd Cathrine who did the original HP-UX port (great gal). I've >>> >>> >also > > >>>cc'd Awais who was involved in the more official HP/rxtx 2.0.5 >>>port/license modifications. >>> >>>Cathrine's work was what encouraged me to help HP with the license >>> >>> >issues. > > >>>Thats about all I can think of to help you at this point. Feel free to >>>forward this email to your HP contacts also. >>> >>>On Mon, 9 Jun 2003, AVIS, Chris wrote: >>> >>> >>> >>>>Trent, >>>> >>>>hopefully you have read my previous email to HP and they will do the >>>>decent thing and cough up a machine for you. >>>> >>>>Looks like we may have to go down the "blind" path for a while. I did >>>>a grep on the code and there are a few occurences of usleep in >>>> >>>> >>SerialImp.c >> >> >>>>but none appear to be compiled out under any non Sun architecture >>>> >>>> >>including >> >> >>>>HP. Any suggestions? >>>> >>>>Regards >>>>Chris >>>> >>>>Chris Avis >>>>WAPS CADCOM Project >>>> >>>>PO Box 1755 Midland WA 6936 >>>>Phone 9374 8617 >>>>Fax 9374 8666 >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Trent Jarvi [mailto:taj at linuxgrrls.org] >>>>Sent: Saturday, 7 June 2003 23:16 >>>>To: AVIS, Chris >>>>Subject: Re: [Rxtx] HPUX 100% CPU Utilisation >>>> >>>> >>>> >>>> >>>>Hi Chris: >>>> >>>>Is it possible that I could get access to this machine to see whats >>>> >>>> >>going >> >> >>>>on? >>>> >>>>I can try helping in a blind remote fashion but the faster way will be >>>> >>>> >>to >> >> >>>>try/test event loop modifications on HP. >>>> >>>>I'm guessing a sleep (up to 10 ms would be typically OK) is just being >>>>compiled out on HP. Not having access to an HP box is the limiting >>>> >>>> >>factor >> >> >>>>for HP development from this end. >>>> >>>>Trent Jarvi >>>>Maintainer www.rxtx.org >>>>taj at www.linux.org.uk >>>> >>>>On Thu, 5 Jun 2003, AVIS, Chris wrote: >>>> >>>> >>>> >>>>>We have recently moved a Serial application from a Windows 2000 box >>>>> >>>>> >to > > >>our >> >> >>>>>HPUX Cluster. We have used the new HPUX Java Communications API >>>>> >>>>> >which > > >>is >> >> >>>>>the HP build of RXTX 2.0-5. >>>>> >>>>>We have experienced a problem with the CPU utilisation running at >>>>> >>>>> >100% > > >>>>under >>>> >>>> >>>>>HPUX. We have not experienced this problem under Windows 2000, and >>>>> >>>>> >the > > >>>>>problem >>>>>exists even if no communications is occuring over the serial link. >>>>> >>>>> >We > > >>have >> >> >>>>>run Java >>>>>with the -Xprof option and it appears to be spending more than 99.5% >>>>> >>>>> >>of >> >> >>>>the >>>> >>>> >>>>>time in the >>>>>native method gnu.io.RXTXPort.eventLoop. Has anyone seen this >>>>> >>>>> >>behaviour on >> >> >>>>>other >>>>>HPUX systems? Is there a solution to this problem? We have tried >>>>> >>>>> >>building >> >> >>>>>both >>>>>RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour >>>>> >>>>> >as > > >>the >> >> >>>>HP >>>> >>>> >>>>>build. >>>>> >>>>>The hardware configuration of our HPUX cluster is a two rp2470 node >>>>> >>>>> >>>>system, >>>> >>>> >>>>>each >>>>>with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running >>>>> >>>>> >>Java >> >> >>>>>1.4.1_01 >>>>>downloaded from HP. >>>>> >>>>>Regards >>>>>Chris >>>>> >>>>>Chris Avis >>>>>WAPS CADCOM Project >>>>> <<...OLE_Obj...>> >>>>>PO Box 1755 Midland WA 6936 >>>>>Phone 9374 8617 >>>>>Fax 9374 8666 >>>>>Mobile 0408 244 734 >>>>>Email chris.avis at baesystems.com >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Rxtx mailing list >>>>>Rxtx at linuxgrrls.org >>>>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rxtx mailing list >>>Rxtx at linuxgrrls.org >>>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >>> >>> >>> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at linuxgrrls.org >>http://undine.linuxgrrls.org/mailman/listinfo/rxtx >> >> >> >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2791 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/ce055180/smime-0001.bin From taj at linuxgrrls.org Wed Jun 11 07:07:00 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 11 Jun 2003 14:07:00 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From chris.avis at baesystems.com Wed Jun 11 19:29:28 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 12 Jun 2003 10:59:28 +0930 Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Further to my posting concerning the argument passed to usleep in the drain_loop function, I checked the man page for Linux and it also appears that a value of 1000000 is considered an invalid argument. I presume that in the Linux and possibly other OS builds the call to usleep in drain_loop actually fails. In general it appears that a value of 1000000 is considered a bad value. Maybe the default case should be removed and explicit delays put in for OSs that require it. Any other opinions? Regards Chris -----Original Message----- Date: Wed, 11 Jun 2003 17:48:03 +0930 From: "AVIS, Chris" To: 'Trent Jarvi' Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , 'Awais Sheikh' , "LUONG, Minh-Tuan" , "SAMIMI, Hooman" Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation Trent, the problem has been identified. The culprit was the usleep in the drain_loop function. The default conditional compilation case is caught for HPUX and has an argument of 1000000. Under HPUX the arg to usleep must be less than 1000000. Hence usleep exits with an error code of "Invalid argument". I used the same value as for sun and the CPU load is now between 1 and 2 percent. I will send you a couple of diff files tomorrow. Apart from the changes to SerialImp.c I also had to modify the configure script. Regards Chris Chris Avis WAPS CADCOM Project PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 -----Original Message----- From: Trent Jarvi [mailto:taj at linuxgrrls.org] Sent: Wednesday, 11 June 2003 14:00 To: AVIS, Chris Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation There is really only two places this could be having problems in the eventLoop(). I gather the usleep() is not working for some reason. You can check its error number for hints there. ERRORS EINTR Interrupted by a signal. EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) I'm guessing its a signal. if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) else printf( "usleep(): timeout" ); Also, the select() is breaking out for some reason. That could be due to pending data or, again, a signal. ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); else if ( eis.ret ) printf( "select(): bytes available\n" ); else printf( "select(): timeout\n" ); This could provide a hint about possibly missing patches required. I'd be surprised if those changes didn't spew out messages. It may well be a missing patch as suggested. I'd have expected this to show up in other systems if it was a problem. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Chris, > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > we have on the CADCOM Project and used the Java Communications API > downloaded > from the HP Java Site. It turns out that the HP offering is a recompile of > the > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > convert > the project over to the Lesser GNU Public License and then repackaged the > software. The following link points to the HP Communications API: > > http://www.hp.com/products1/unix/java/com_api/index.html > > There is currently no support from HP for this software. What would it take > to get HP to contribute a new/old/traded/reconditioned 700 series > workstation > to support this work. Given the contribution from Trent, I would say this is > the very least that HP could do to contribute. Any suggestions ? > > Regards > Chris > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Monday, 9 June 2003 14:49 > To: AVIS, Chris > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > rxtx at linuxgrrls.org > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture > including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to > our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We > have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour > on > > > other > > > HPUX systems? Is there a solution to this problem? We have tried > building > > > both > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > the > > HP > > > build. > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > system, > > > each > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > > 1.4.1_01 > > > downloaded from HP. > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > <<...OLE_Obj...>> > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > Mobile 0408 244 734 > > > Email chris.avis at baesystems.com > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 11 19:42:49 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 02:42:49 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: The usleep appears to be on Linux. The man page does suggest values that large could cause problems on some systems. It would be fairly easy to just make it 999999 and then not worry :) Its not going to break anything to do that. [] time ./a.out usleep(): timeout real 0m1.010s user 0m0.000s sys 0m0.020s #include int main(){ if( usleep(1000000) ) printf( "usleep(): %s\n", strerror(errno) ); else printf( "usleep(): timeout" ); exit(0); } On Thu, 12 Jun 2003, AVIS, Chris wrote: > Further to my posting concerning the argument passed to usleep in the > drain_loop function, I checked the man page for Linux and it also appears > that a value of 1000000 is considered an invalid argument. I presume that > in the Linux and possibly other OS builds the call to usleep in drain_loop > actually fails. In general it appears that a value of 1000000 is > considered a bad value. Maybe the default case should be removed and > explicit delays put in for OSs that require it. Any other opinions? > > Regards > Chris > > -----Original Message----- > Date: Wed, 11 Jun 2003 17:48:03 +0930 > From: "AVIS, Chris" > To: 'Trent Jarvi' > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > 'Awais Sheikh' , > "LUONG, Minh-Tuan" , > "SAMIMI, Hooman" > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > Trent, > > the problem has been identified. The culprit was the usleep in > the drain_loop function. The default conditional compilation case > is caught for HPUX and has an argument of 1000000. Under HPUX > the arg to usleep must be less than 1000000. Hence usleep exits > with an error code of "Invalid argument". I used the same value > as for sun and the CPU load is now between 1 and 2 percent. > > I will send you a couple of diff files tomorrow. Apart from the > changes to SerialImp.c I also had to modify the configure script. > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Wednesday, 11 June 2003 14:00 > To: AVIS, Chris > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > There is really only two places this could be having problems in the > eventLoop(). > > I gather the usleep() is not working for some reason. You can check its > error number for hints there. > > ERRORS > EINTR Interrupted by a signal. > > EINVAL usec is not smaller than 1000000. (On systems where that > is > considered an error.) > > I'm guessing its a signal. > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > else printf( "usleep(): timeout" ); > > Also, the select() is breaking out for some reason. That could be due to > pending data or, again, a signal. > > ERRORS > EBADF An invalid file descriptor was given in one of the sets. > > EINTR A non blocked signal was caught. > > EINVAL n is negative. > > ENOMEM select was unable to allocate memory for internal tables. > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > else if ( eis.ret ) printf( "select(): bytes available\n" ); > else printf( "select(): timeout\n" ); > > This could provide a hint about possibly missing patches required. > I'd be surprised if those changes didn't spew out messages. > > It may well be a missing patch as suggested. I'd have expected this to > show up in other systems if it was a problem. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Chris, > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > we have on the CADCOM Project and used the Java Communications API > > downloaded > > from the HP Java Site. It turns out that the HP offering is a recompile of > > the > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > convert > > the project over to the Lesser GNU Public License and then repackaged the > > software. The following link points to the HP Communications API: > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > There is currently no support from HP for this software. What would it > take > > to get HP to contribute a new/old/traded/reconditioned 700 series > > workstation > > to support this work. Given the contribution from Trent, I would say this > is > > the very least that HP could do to contribute. Any suggestions ? > > > > Regards > > Chris > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Monday, 9 June 2003 14:49 > > To: AVIS, Chris > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > rxtx at linuxgrrls.org > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > Hi Chris, > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > Don't be afraid to remind them of that. I could have forced them to pay > > for an HP box at the time but just did the right thing as they should now. > > > > It is not easy to know whats going on. The one thing I may suggest is > > replacing the usleep with a sleep. The eventLoop should be fairly > > intuitive without digging into the called functions below it. Just try to > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > will start to happen but 1 ms should make the problem all but go away. > > > > Maybe that select() is not doing what I expect? Are you sitting with > > unread data? > > > > If this is really critical you could always use a pc and tcp/ip to > > get the data where it needs to go... > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > port/license modifications. > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > Thats about all I can think of to help you at this point. Feel free to > > forward this email to your HP contacts also. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Trent, > > > > > > hopefully you have read my previous email to HP and they will do the > > > decent thing and cough up a machine for you. > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > a grep on the code and there are a few occurences of usleep in > SerialImp.c > > > but none appear to be compiled out under any non Sun architecture > > including > > > HP. Any suggestions? > > > > > > Regards > > > Chris > > > > > > Chris Avis > > > WAPS CADCOM Project > > > > > > PO Box 1755 Midland WA 6936 > > > Phone 9374 8617 > > > Fax 9374 8666 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, 7 June 2003 23:16 > > > To: AVIS, Chris > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > Hi Chris: > > > > > > Is it possible that I could get access to this machine to see whats > going > > > on? > > > > > > I can try helping in a blind remote fashion but the faster way will be > to > > > try/test event loop modifications on HP. > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > compiled out on HP. Not having access to an HP box is the limiting > factor > > > > > for HP development from this end. > > > > > > Trent Jarvi > > > Maintainer www.rxtx.org > > > taj at www.linux.org.uk > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > our > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > is > > > > the HP build of RXTX 2.0-5. > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > under > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > problem > > > > exists even if no communications is occuring over the serial link. We > > have > > > > run Java > > > > with the -Xprof option and it appears to be spending more than 99.5% > of > > > the > > > > time in the > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > behaviour > > on > > > > other > > > > HPUX systems? Is there a solution to this problem? We have tried > > building > > > > both > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > the > > > HP > > > > build. > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > system, > > > > each > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > Java > > > > 1.4.1_01 > > > > downloaded from HP. > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > <<...OLE_Obj...>> > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > Mobile 0408 244 734 > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Wed Jun 11 20:06:05 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 03:06:05 +0100 (BST) Subject: FW: [Rxtx] HPUX 100% CPU Utilisation (fwd) In-Reply-To: References: <41842F7B366BD611A8E100D0B7910EC20ED8D8@KENTFP1> Message-ID: Also.. The drain_loop() for dealing with differences between linux and (Solaris/HP-UX). For detecting output buffer, linux has a TIOCSERGETLSR ioctl call which can be used to detect when the output buffer is empty. The drain_loop is not used on linux; it compiles out. I put the drain_loop in for Solaris and I assume HP-UX uses it too. It monitors for same condition as the TIOCSERGETLSR does above. The entire drainloop is avoided with: #if !defined(TIOCSERGETLSR) & !defined(WIN32) ... in init_threads(). So I think all you need to do is go with the usleep() time used for Solaris in the drain_loop(): #if defined(__sun__) /* FIXME: No time to test on all OS's for production */ usleep(5000); #else usleep(1000000); #endif /* __sun__ */ Five milliseconds is more reasonable anyhow. I just had no way of testing the above on HP-UX at the time. On Thu, 12 Jun 2003, Trent Jarvi wrote: > > The usleep appears to be on Linux. The man page does suggest values that > large could cause problems on some systems. It would be fairly easy to > just make it 999999 and then not worry :) Its not going to break anything > to do that. > > [] time ./a.out > usleep(): timeout > real 0m1.010s > user 0m0.000s > sys 0m0.020s > > > #include > int main(){ > if( usleep(1000000) ) > printf( "usleep(): %s\n", strerror(errno) ); > else printf( "usleep(): timeout" ); > exit(0); > } > > > On Thu, 12 Jun 2003, AVIS, Chris wrote: > > > Further to my posting concerning the argument passed to usleep in the > > drain_loop function, I checked the man page for Linux and it also appears > > that a value of 1000000 is considered an invalid argument. I presume that > > in the Linux and possibly other OS builds the call to usleep in drain_loop > > actually fails. In general it appears that a value of 1000000 is > > considered a bad value. Maybe the default case should be removed and > > explicit delays put in for OSs that require it. Any other opinions? > > > > Regards > > Chris > > > > -----Original Message----- > > Date: Wed, 11 Jun 2003 17:48:03 +0930 > > From: "AVIS, Chris" > > To: 'Trent Jarvi' > > Cc: "'WIGNALL,CHRIS (HP-Australia,ex2)'" , > > 'Awais Sheikh' , > > "LUONG, Minh-Tuan" , > > "SAMIMI, Hooman" > > Subject: RE: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > Trent, > > > > the problem has been identified. The culprit was the usleep in > > the drain_loop function. The default conditional compilation case > > is caught for HPUX and has an argument of 1000000. Under HPUX > > the arg to usleep must be less than 1000000. Hence usleep exits > > with an error code of "Invalid argument". I used the same value > > as for sun and the CPU load is now between 1 and 2 percent. > > > > I will send you a couple of diff files tomorrow. Apart from the > > changes to SerialImp.c I also had to modify the configure script. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Wednesday, 11 June 2003 14:00 > > To: AVIS, Chris > > Cc: 'WIGNALL,CHRIS (HP-Australia,ex2)' > > Subject: Re: FW: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > There is really only two places this could be having problems in the > > eventLoop(). > > > > I gather the usleep() is not working for some reason. You can check its > > error number for hints there. > > > > ERRORS > > EINTR Interrupted by a signal. > > > > EINVAL usec is not smaller than 1000000. (On systems where that > > is > > considered an error.) > > > > I'm guessing its a signal. > > > > if( usleep(time) ) printf( "usleep(): %s\n", strerror(errno) ) > > else printf( "usleep(): timeout" ); > > > > Also, the select() is breaking out for some reason. That could be due to > > pending data or, again, a signal. > > > > ERRORS > > EBADF An invalid file descriptor was given in one of the sets. > > > > EINTR A non blocked signal was caught. > > > > EINVAL n is negative. > > > > ENOMEM select was unable to allocate memory for internal tables. > > > > eis.ret = SELECT( eis.fd + 1, &eis.rfds, NULL, NULL, &eis.tv_sleep ); > > if( eis.ret < 0 ) printf( "select(): %s\n", strerror(errno) ); > > else if ( eis.ret ) printf( "select(): bytes available\n" ); > > else printf( "select(): timeout\n" ); > > > > This could provide a hint about possibly missing patches required. > > I'd be surprised if those changes didn't spew out messages. > > > > It may well be a missing patch as suggested. I'd have expected this to > > show up in other systems if it was a problem. > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > Chris, > > > > > > we have ported one of our equipment alarm interfaces to the HPUX Cluster > > > we have on the CADCOM Project and used the Java Communications API > > > downloaded > > > from the HP Java Site. It turns out that the HP offering is a recompile of > > > the > > > Open Source RXTX Project started by Trent Jarvi. HP convinced Trent to > > > convert > > > the project over to the Lesser GNU Public License and then repackaged the > > > software. The following link points to the HP Communications API: > > > > > > http://www.hp.com/products1/unix/java/com_api/index.html > > > > > > There is currently no support from HP for this software. What would it > > take > > > to get HP to contribute a new/old/traded/reconditioned 700 series > > > workstation > > > to support this work. Given the contribution from Trent, I would say this > > is > > > the very least that HP could do to contribute. Any suggestions ? > > > > > > Regards > > > Chris > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Monday, 9 June 2003 14:49 > > > To: AVIS, Chris > > > Cc: LUONG, Minh-Tuan; awais.sheikh at hp.com; catherine_guiollot at hp.com; > > > rxtx at linuxgrrls.org > > > Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > Hi Chris, > > > > > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > > > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > > > > > Don't be afraid to remind them of that. I could have forced them to pay > > > for an HP box at the time but just did the right thing as they should now. > > > > > > It is not easy to know whats going on. The one thing I may suggest is > > > replacing the usleep with a sleep. The eventLoop should be fairly > > > intuitive without digging into the called functions below it. Just try to > > > > > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > > > will start to happen but 1 ms should make the problem all but go away. > > > > > > Maybe that select() is not doing what I expect? Are you sitting with > > > unread data? > > > > > > If this is really critical you could always use a pc and tcp/ip to > > > get the data where it needs to go... > > > > > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > > > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > > > port/license modifications. > > > > > > Cathrine's work was what encouraged me to help HP with the license issues. > > > > > > Thats about all I can think of to help you at this point. Feel free to > > > forward this email to your HP contacts also. > > > > > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > > > > > Trent, > > > > > > > > hopefully you have read my previous email to HP and they will do the > > > > decent thing and cough up a machine for you. > > > > > > > > Looks like we may have to go down the "blind" path for a while. I did > > > > a grep on the code and there are a few occurences of usleep in > > SerialImp.c > > > > but none appear to be compiled out under any non Sun architecture > > > including > > > > HP. Any suggestions? > > > > > > > > Regards > > > > Chris > > > > > > > > Chris Avis > > > > WAPS CADCOM Project > > > > > > > > PO Box 1755 Midland WA 6936 > > > > Phone 9374 8617 > > > > Fax 9374 8666 > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > > Sent: Saturday, 7 June 2003 23:16 > > > > To: AVIS, Chris > > > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > > > > > > > > > > > Hi Chris: > > > > > > > > Is it possible that I could get access to this machine to see whats > > going > > > > on? > > > > > > > > I can try helping in a blind remote fashion but the faster way will be > > to > > > > try/test event loop modifications on HP. > > > > > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > > > compiled out on HP. Not having access to an HP box is the limiting > > factor > > > > > > > for HP development from this end. > > > > > > > > Trent Jarvi > > > > Maintainer www.rxtx.org > > > > taj at www.linux.org.uk > > > > > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > > > > > We have recently moved a Serial application from a Windows 2000 box to > > > our > > > > > HPUX Cluster. We have used the new HPUX Java Communications API which > > is > > > > > the HP build of RXTX 2.0-5. > > > > > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > > > under > > > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > > > problem > > > > > exists even if no communications is occuring over the serial link. We > > > have > > > > > run Java > > > > > with the -Xprof option and it appears to be spending more than 99.5% > > of > > > > the > > > > > time in the > > > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this > > behaviour > > > on > > > > > other > > > > > HPUX systems? Is there a solution to this problem? We have tried > > > building > > > > > both > > > > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as > > > the > > > > HP > > > > > build. > > > > > > > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > > > > system, > > > > > each > > > > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running > > Java > > > > > 1.4.1_01 > > > > > downloaded from HP. > > > > > > > > > > Regards > > > > > Chris > > > > > > > > > > Chris Avis > > > > > WAPS CADCOM Project > > > > > <<...OLE_Obj...>> > > > > > PO Box 1755 Midland WA 6936 > > > > > Phone 9374 8617 > > > > > Fax 9374 8666 > > > > > Mobile 0408 244 734 > > > > > Email chris.avis at baesystems.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rxtx mailing list > > > > > Rxtx at linuxgrrls.org > > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Wed Jun 11 14:40:26 2003 From: adamh at basis.com (Adam Hawthorne) Date: Wed, 11 Jun 2003 14:40:26 -0600 Subject: [Rxtx] windows XP Message-ID: <20030611204026.GA2852@basis.com> Hi, I'm trying to use rxtx for a product in an application we write. I've built it for several other platforms and it has been successful, but trying to build under cygwin has proven quite difficult. All I really care about is the dll that it builds, which we intend to distribute. Is there any way anyone could send me a prebuilt version? Please cc me or email me directly. Thanks, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030611/1a61e539/attachment-0001.bin From taj at linuxgrrls.org Thu Jun 12 05:06:10 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:06:10 +0100 (BST) Subject: [Rxtx] Re: RXTX 2.0.5 Diff Files In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8DA@KENTFP1> Message-ID: Hi Chris, The patches look good to me. I'm guessing the split cases in code around usleep() is just wrong on my part. Thinking back, I recall someone with *bsd mentioning excess CPU use. I'll take a look at freebsd when I get time. The code may have caused problems on several OS's and is probably not needed. I forwarded the patches to Awais so he may do a review of them also. On Thu, 12 Jun 2003, AVIS, Chris wrote: > Trent, > > please find attached the diff files for the changes I made to SerialImp.c > and configure. > SerialImp is as we discussed in emails. Configure changes were needed > because I > was using Java 1.3 and 1.4 from HP. We also used gcc which I have found over > the > years to be more reliable that the HP offering. I am not sure if the > configure changes > follow convention but they worked for me. I hope they help. > > Regards > Chris > <> > Chris Avis > WAPS CADCOM Project > <<...OLE_Obj...>> > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > Mobile 0408 244 734 > Email chris.avis at baesystems.com > > > > From taj at linuxgrrls.org Thu Jun 12 05:24:34 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 12:24:34 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: Hi Richard I had been reading your efforts to have the library work with multiple installs. The main reason for not saying much is I don't know how this relates to the FHS. After seeing other attempts (Kaffe) to mix the Java tree and other linux directories, I'm very nervous about starting the direction you tried. As an example problem that may start showing up if we do this.. Kaffe also has a shell implementation of commapi and may do further work with it. If we use the jre/ directories, the worst thing that could happen is the files need to be reinstalled. If we jump out of this location, we may run into confusion with the kaffee libraries. On Tue, 3 Jun 2003, Richard Welty wrote: > On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > > it turns out that jni_md.h is in the subdirectory include/linux in this > > particular distribution. i'm going to continue slashing and burning my > > way > > through this, probably by symlinking jni_md.h in one level up. > > ok, that change got it to compile, now for the install glitch. from the > makefile: > > RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) > > now the way things set up, JPATH already has jre/ in it, so this gets > doubled and points at a non-existent directory. hand editing jre/ out of > RXTX_PATH got it to finish. i subsequently moved the rxtx files over to > /usr/local/java/lib so future java upgrades won't remove them > automagically, and now it seems to be working ok. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rwelty at averillpark.net Thu Jun 12 06:04:58 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:04:58 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > I had been reading your efforts to have the library work with multiple > installs. The main reason for not saying much is I don't know how this > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > tree and other linux directories, I'm very nervous about starting > the direction you tried. hmm. then how about ./configure --local-java-libs=/usr/local/java/lib where the default is in the jre tree? for most users it will continue to do what it does now. i wouldn't be so bothered by the reinstall if the makefile generated by ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each reinstall tends to be a bit of a party right now, and i'm not clear on what the issue is. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 06:24:40 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 13:24:40 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 12:24:34 +0100 (BST) Trent Jarvi wrote: > > I had been reading your efforts to have the library work with multiple > > installs. The main reason for not saying much is I don't know how this > > relates to the FHS. After seeing other attempts (Kaffe) to mix the Java > > tree and other linux directories, I'm very nervous about starting > > the direction you tried. > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue to do > what it does now. > That sounds great. Would you mind putting a patch together? > i wouldn't be so bothered by the reinstall if the makefile generated by > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). each > reinstall tends to be a bit of a party right now, and i'm not clear on > what the issue is. hmm. You may check `which java` and see if $JAVA_HOME is set as expected or even unset (should be ok as long as java is in the path). Feel free to mail me a typescript of ./configure && make install if you see it again. From rwelty at averillpark.net Thu Jun 12 06:39:33 2003 From: rwelty at averillpark.net (Richard Welty) Date: Thu, 12 Jun 2003 08:39:33 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > hmm. then how about > > ./configure --local-java-libs=/usr/local/java/lib > > where the default is in the jre tree? for most users it will continue > to do > > what it does now. > That sounds great. Would you mind putting a patch together? i'll take a look. i'm not particularly familiar with configure internals, but probably i need to more than i currently do. > > i wouldn't be so bothered by the reinstall if the makefile generated by > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > each > > reinstall tends to be a bit of a party right now, and i'm not clear on > > what the issue is. > > hmm. You may check `which java` and see if $JAVA_HOME is set as > expected > or even unset (should be ok as long as java is in the path). i wonder how much of it has to do with the fact that i've actually got the full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, it's j2sdk 1.4.1_02). some of the stuff moves about between the two. my environment setup looks like this: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre which is what most of the other java stuff seems to want to see when the sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in ${JAVA_HOME}/bin in this arrangement. other things are in slightly different places as well. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From taj at linuxgrrls.org Thu Jun 12 07:46:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 14:46:16 +0100 (BST) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Thu, 12 Jun 2003, Richard Welty wrote: > On Thu, 12 Jun 2003 13:24:40 +0100 (BST) Trent Jarvi wrote: > > > hmm. then how about > > > > ./configure --local-java-libs=/usr/local/java/lib > > > > where the default is in the jre tree? for most users it will continue > > to do > > > what it does now. > > > That sounds great. Would you mind putting a patch together? > > i'll take a look. i'm not particularly familiar with configure internals, > but probably i need to more than i currently do. > > > > i wouldn't be so bothered by the reinstall if the makefile generated by > > > ./configure were working properly on my system (RH 8.0, jre 1.4.1_02). > > each > > > reinstall tends to be a bit of a party right now, and i'm not clear on > > > what the issue is. > > > > hmm. You may check `which java` and see if $JAVA_HOME is set as > > expected > > or even unset (should be ok as long as java is in the path). > > i wonder how much of it has to do with the fact that i've actually got the > full sdk installed (i was mistaken when i refered to jre 1.4.1_02 above, > it's j2sdk 1.4.1_02). some of the stuff moves about between the two. > > my environment setup looks like this: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre I was not aware this was 'standard.' rxtx configure would expect the JAVA_HOME to be /usr/java/j2sdk1.4.1_02 The above will cause problems as things are now. here are typical instructions I've just tried to work with. http://java.sun.com/j2ee/tools/j2eeide-toolkit/lininstall_2_0.html Download and Install J2SE, J2EE, and Forte CE 1. Download and install the J2SE 1.3.1_01 SDK for Linux. http://java.sun.com/j2se/1.3/ 2. Download and install the J2EE 1.3 SDK (j2sdkee1.3) for Linux. http://java.sun.com/j2ee/sdk_1.3/ Install the J2EE IDE Toolkit 1. Set the environment variable JAVA_HOME to the directory where you installed J2SE. For example, you could use the default bash shell to set JAVA_HOME as follows: export JAVA_HOME=install_path Perhaps its just random luck that your JAVA_HOME did not cause problems before? Then again, I'm not sure where JAVA_HOME is formally documented. I've not tried mixing the jre and sdk downloads as the sdk comes with a jre. > > which is what most of the other java stuff seems to want to see when the > sdk is installed. javac and java are in ${JDK_HOME}/bin, rather than in > ${JAVA_HOME}/bin in this arrangement. other things are in slightly > different places as well. > > richard > -- > Richard Welty rwelty at averillpark.net > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From adamh at basis.com Thu Jun 12 09:35:28 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 09:35:28 -0600 Subject: [Rxtx] rxtx on non-linux platforms Message-ID: <20030612153528.GA3170@basis.com> Hello, I'm new to rxtx, and I'm trying to use it for an interpreter product where we give the users programmatic access to the serial ports. We distribute our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all of them to make our installation and build process easier. Thankfully, we have gotten rxtx to build easily on Linux, and it installs and works just as we expect. However, when trying to build on any other system, we have various problems. Most often, the file SerialImp.c fails because certain constants aren't defined because the include files are incorrect. In most cases we've found the constants needed, but I'd like to know if there's something we're doing wrong if we're having this much trouble. Can anyone give us some hint about how to build this on any of the platforms I listed above? Thanks in advance. Also, I would like to test rxtx on Windows, but building it on Windows has been as much of a problem as on any other platform, so if someone could send me a dll just to see if it works, that would be incredibly useful. Thanks for your help, Adam Hawthorne -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/10cdfa26/attachment-0001.bin From taj at linuxgrrls.org Thu Jun 12 10:27:31 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 12 Jun 2003 17:27:31 +0100 (BST) Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: <20030612153528.GA3170@basis.com> References: <20030612153528.GA3170@basis.com> Message-ID: w32 builds can be less than fun. Which version of rxtx are you looking for? I'll build a copy if its not already around. On Thu, 12 Jun 2003, Adam Hawthorne wrote: > Hello, > > I'm new to rxtx, and I'm trying to use it for an interpreter product where > we give the users programmatic access to the serial ports. We distribute > our product on 8 platforms, including Windows, Linux, Solaris x86/Sparc, > AIX, HP-UX, Digital UNIX, and SCO UnixWare. I'd like to use RXTX for all > of them to make our installation and build process easier. Thankfully, we > have gotten rxtx to build easily on Linux, and it installs and works just > as we expect. However, when trying to build on any other system, we have > various problems. Most often, the file SerialImp.c fails because certain > constants aren't defined because the include files are incorrect. In most > cases we've found the constants needed, but I'd like to know if there's > something we're doing wrong if we're having this much trouble. > > Can anyone give us some hint about how to build this on any of the > platforms I listed above? Thanks in advance. I'd be interested in looking at any problems you have with builds. Of the platforms mentioned I've had experience with the Solaris Linux and w32. There is some level of testing done for these systems before 2.1 releases and 2.0 gets all those changes. Mac OSX should also be in good shape. AIX: has built in the past for some but often the last changes required don't get sent back. New issues may have been introduced since the last person had a look at AIX. HP-UX: We have just about finished looking at builds/runtime on the mail-list. SCO variants: These do build for SCO last I heard. Fixes required should be minimal if a patch did not make it back. Digital UNIX: I've tested the compile time at the school computer in the past and could look at any issues in the compile. Solaris: x86 2.6/2.8 for building in vmware are available here. Very little testing is done on x86 Solaris Sparcs I've not got ready access to but it is well tested. I've got a SPARC station 1+ that was donated but getting an OS onto it proved to be another project. There has also recently been a patch posted to the list for HP-UX that may well fix 100% cpu use for these if you run into that problem on Unix systems. Contributers for each system are listed at http://www.rxtx.org/credits.html though there is no garantee of support from anyone listed there, they may have tips. HP-UX and (last I saw :) SCO offer binaries of rxtx also. These binaries tend to be done by vendors as time permits. You will probably find only one or two versions available. Sadly its very difficult to offer all the binaries from rxtx.org. We provide what we can. While, we get ready to release 2.0 and 2.1, it would be a good time to add any build fixes required. > > Also, I would like to test rxtx on Windows, but building it on Windows has > been as much of a problem as on any other platform, so if someone could > send me a dll just to see if it works, that would be incredibly useful. Let me know which version version of rxtx you are using (2.0 or 2.1). In the example you described, I would think 2.1 would be a good choice but you may want to use Sun's CommAPI jar + rxtx 2.0. I can compile the w32 for you. Its also possible to set up an account with a cross compiler installed for w32 (I've failed misserably trying to get other cross-compilers installed). That way you are free to modify the w32 code or even set up the same environment on your machine. The w32 compiling on w32 can work but often frustrating details with escaped characters in the Makefile vary between versions. I tend to hack the Makefile to work for each one when doing devel/test cycles. Of the above ports, w32 was the most troublesome but the rxtx 2.1 prerelease should behave fine on the platforms you are interested in excluding the problems mentioned on http://www.rxtx.org/index.html : # Baudrates of 128000 * N may have problems # Add a method for re-checking for valid ports # Add support in RXTX to specify valid ports on the PC. # Adding support for half duplex serial communication. # Error events for parity errors. # Baudrate of 5 # serial break time # terminating character checking for reads # Event listeners need to be added when the port is opened to initialize the native structures. # Closing a port from an event listener results in a deadlock. # Closing a port without adding an event listener results in a deadlock. Hope that gives you a good feel for everything. It would be a good time to get any compile fixes for the OS's you mention in. From adamh at basis.com Thu Jun 12 10:45:51 2003 From: adamh at basis.com (Adam Hawthorne) Date: Thu, 12 Jun 2003 10:45:51 -0600 Subject: [Rxtx] rxtx on non-linux platforms In-Reply-To: References: <20030612153528.GA3170@basis.com> Message-ID: <20030612164551.GD3170@basis.com> On Thu, Jun 12, 2003 at 05:27:31PM +0100, Trent Jarvi wrote: > > > w32 builds can be less than fun. Which version of rxtx are you looking > for? I'll build a copy if its not already around. I was working with 2.0-5, but please let me know if there's a better candidate. I would like to continue to use the javax.comm package because then I don't have to rework any java code (all of which is new to me), but I'm even willing to change that code if necessary to get it up and running. Thanks again! Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030612/660dafbf/attachment-0001.bin From taj at linuxgrrls.org Mon Jun 16 10:05:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 17:05:07 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F4@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > Where can I find out more information on how to properly remove the lock > files. I have tried to remove the LOCK file manually with code but > wvdial is using the a lock file also and the next time my program runs > it gives me an error pointing to the wvdial lock file. Thanks for > helping. > The proper way to remove the lock file is to remove any event listener and close the port. i.e. don't use the port. The code in the close() method in rxtx should remove the lockfile. As rxtx does not implement the sharing of ports between applications, the lockfile and unlocking is currently in the native open and close respectively. If there is no application is using the port and there is a lock file, rxtx should give a warning about removing a stale lockfile. If no application is using the port and the lockfile is causing an error rather than a warning, there is a bug in rxtx. The PID of the process that created the lockfile should be in the lockfile on linux. rxtx basically does kill -0 PID and checks the return to see if the process is still alive. If not, rxtx removes the lockfile with warning. If the PID is found to be alive, rxtx will error. > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, June 07, 2003 10:21 AM > To: Java RXTX discussion; Wilson, Allan > Subject: Re: [Rxtx] lock file question > > > The error message is informative and will not be removed from rxtx. > > The previous application (possibly yours) did not remove the lock file > before exiting. I suspect if you close the port before exiting the > message will go away. Closing the port will remove your lock file. > > There is a (very bad) option in rxtx configure to remove lock file > support > on Unix if you do not like the messages. > > It is my understanding that SUSE has recently moved its lock file > location. This suggests that the FHS has suggested a new location. > I've > not had time to review SUSE's action but rxtx will continue to support > the > FHS and cause problems on non compliant systems unless a more suitable > standard is found. > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > Hopefully this is an easy question. I am getting the following warning > > message: > > > > RXTX Warning: Removing stale lock file. > > > > Although this warning comes up on the display it does not cause a > > problem. I do not want the user to be able to see this error message > so > > I need to either fix the problem or supress error messages from going > to > > standard out. Any idea? > > > > Allan Wilson > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From taj at linuxgrrls.org Mon Jun 16 12:11:17 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 19:11:17 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: On Mon, 16 Jun 2003, Wilson, Allan wrote: > The lock file still exists after my program exits. I have no way of > closing the port other than exiting my program. The only thing I do with > the port is reference it and the libraries for the signature pad I am > using handles the rest. I am getting a warning saying the stale lock > file exists and that it will go ahead and create a new one. The problem > is that the warning shows on the users station and we do not want them > to see errors. If I delete the lockfile after my program closes and > before it runs again I get an error message saying that the lockfile > exists for another port. I don't know enough to determine if it is a > problem with how I use RXTX or if it is a problem with the libraries > that I am using for my signature pad. Any suggestions. Thanks for the > quick reply. > It sounds like a library you are using is not closing the port. In SerialImp.c the following code is reporting warnings. Sounds like you want to stop all warnings. You could just remove the fprintf and there will be no more warnings: /*---------------------------------------------------------- report_warning accept: string to send to report as an message perform: send the string to stderr or however it needs to be reported. return: none exceptions: none comments: ----------------------------------------------------------*/ void report_warning(char *msg) { #ifndef DEBUG_MW fprintf(stderr, msg); #else mexWarnMsgTxt( (const char *) msg ); #endif /* DEBUG_MW */ } The thing that confuses me is RXTXPort.java has a finalize() which calls close(). I'm curious about how that is being missed even if the application/library does not close the port but is exiting normally. Is it possible to reproduce the problem here? I assume this is rxtx 2.0-5? > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > Where can I find out more information on how to properly remove the > lock > > files. I have tried to remove the LOCK file manually with code but > > wvdial is using the a lock file also and the next time my program runs > > it gives me an error pointing to the wvdial lock file. Thanks for > > helping. > > > > > The proper way to remove the lock file is to remove any event > listener and close the port. i.e. don't use the port. The code in the > > close() method in rxtx should remove the lockfile. As rxtx does not > implement the sharing of ports between applications, the lockfile and > unlocking is currently in the native open and close respectively. > > If there is no application is using the port and there is a lock file, > rxtx should give a warning about removing a stale lockfile. If no > application is using the port and the lockfile is causing an error > rather than a warning, there is a bug in rxtx. > > The PID of the process that created the lockfile should be in the > lockfile > on linux. rxtx basically does kill -0 PID and checks the return to see > if > the process is still alive. If not, rxtx removes the lockfile with > warning. If the PID is found to be alive, rxtx will error. > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, June 07, 2003 10:21 AM > > To: Java RXTX discussion; Wilson, Allan > > Subject: Re: [Rxtx] lock file question > > > > > > The error message is informative and will not be removed from rxtx. > > > > The previous application (possibly yours) did not remove the lock file > > > before exiting. I suspect if you close the port before exiting the > > message will go away. Closing the port will remove your lock file. > > > > There is a (very bad) option in rxtx configure to remove lock file > > support > > on Unix if you do not like the messages. > > > > It is my understanding that SUSE has recently moved its lock file > > location. This suggests that the FHS has suggested a new location. > > I've > > not had time to review SUSE's action but rxtx will continue to support > > the > > FHS and cause problems on non compliant systems unless a more suitable > > standard is found. > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > Hopefully this is an easy question. I am getting the following > warning > > > message: > > > > > > RXTX Warning: Removing stale lock file. > > > > > > Although this warning comes up on the display it does not cause a > > > problem. I do not want the user to be able to see this error message > > so > > > I need to either fix the problem or supress error messages from > going > > to > > > standard out. Any idea? > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > From skejariwal at perigee.com Mon Jun 16 12:44:23 2003 From: skejariwal at perigee.com (Shreyas Kejariwal) Date: Mon, 16 Jun 2003 14:44:23 -0400 Subject: [Rxtx] lock file question References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Hi everyone, On the same note, I encountered the same problem where I would see the stale lock messages on restarting my App. I tried ,exactly what was suggested then and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But this did not help much. The problem would still occur occasionally. Needless to say, It was hard to replicate. After some more digging what we found out was that we were sending data to the serial port, say /tty/S1 without anything being connected to this port. So it was assumed that maybe the buffer is not cleared when we release the port from within our application. So we redesigned our App to not send data blindly to the port. This actually worked and we no longer see the stale lock warning. All $0.02 welcome. Shreyas ----------------------------------------------- Shreyas Kejariwal Perigee LLC Tel: 315-453 7842 x 42 ----- Original Message ----- From: "Trent Jarvi" To: "Wilson, Allan" Cc: Sent: Monday, June 16, 2003 2:11 PM Subject: RE: [Rxtx] lock file question > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > The lock file still exists after my program exits. I have no way of > > closing the port other than exiting my program. The only thing I do with > > the port is reference it and the libraries for the signature pad I am > > using handles the rest. I am getting a warning saying the stale lock > > file exists and that it will go ahead and create a new one. The problem > > is that the warning shows on the users station and we do not want them > > to see errors. If I delete the lockfile after my program closes and > > before it runs again I get an error message saying that the lockfile > > exists for another port. I don't know enough to determine if it is a > > problem with how I use RXTX or if it is a problem with the libraries > > that I am using for my signature pad. Any suggestions. Thanks for the > > quick reply. > > > > It sounds like a library you are using is not closing the port. In > SerialImp.c the following code is reporting warnings. Sounds like you > want to stop all warnings. You could just remove the fprintf and there > will be no more warnings: > > /*---------------------------------------------------------- > report_warning > > accept: string to send to report as an message > perform: send the string to stderr or however it needs to be reported. > return: none > exceptions: none > comments: > ----------------------------------------------------------*/ > void report_warning(char *msg) > { > #ifndef DEBUG_MW > fprintf(stderr, msg); > #else > mexWarnMsgTxt( (const char *) msg ); > #endif /* DEBUG_MW */ > } > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. > > Is it possible to reproduce the problem here? I assume this is rxtx > 2.0-5? > > > On Mon, 16 Jun 2003, Wilson, Allan wrote: > > > > > Where can I find out more information on how to properly remove the > > lock > > > files. I have tried to remove the LOCK file manually with code but > > > wvdial is using the a lock file also and the next time my program runs > > > it gives me an error pointing to the wvdial lock file. Thanks for > > > helping. > > > > > > > > > The proper way to remove the lock file is to remove any event > > listener and close the port. i.e. don't use the port. The code in the > > > > close() method in rxtx should remove the lockfile. As rxtx does not > > implement the sharing of ports between applications, the lockfile and > > unlocking is currently in the native open and close respectively. > > > > If there is no application is using the port and there is a lock file, > > rxtx should give a warning about removing a stale lockfile. If no > > application is using the port and the lockfile is causing an error > > rather than a warning, there is a bug in rxtx. > > > > The PID of the process that created the lockfile should be in the > > lockfile > > on linux. rxtx basically does kill -0 PID and checks the return to see > > if > > the process is still alive. If not, rxtx removes the lockfile with > > warning. If the PID is found to be alive, rxtx will error. > > > > > > > > -----Original Message----- > > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > > Sent: Saturday, June 07, 2003 10:21 AM > > > To: Java RXTX discussion; Wilson, Allan > > > Subject: Re: [Rxtx] lock file question > > > > > > > > > The error message is informative and will not be removed from rxtx. > > > > > > The previous application (possibly yours) did not remove the lock file > > > > > before exiting. I suspect if you close the port before exiting the > > > message will go away. Closing the port will remove your lock file. > > > > > > There is a (very bad) option in rxtx configure to remove lock file > > > support > > > on Unix if you do not like the messages. > > > > > > It is my understanding that SUSE has recently moved its lock file > > > location. This suggests that the FHS has suggested a new location. > > > I've > > > not had time to review SUSE's action but rxtx will continue to support > > > the > > > FHS and cause problems on non compliant systems unless a more suitable > > > standard is found. > > > > > > http://www.pathname.com/fhs/2.2/fhs-5.9.html > > > > > > On Tue, 3 Jun 2003, K. Allan Wilson wrote: > > > > > > > Hopefully this is an easy question. I am getting the following > > warning > > > > message: > > > > > > > > RXTX Warning: Removing stale lock file. > > > > > > > > Although this warning comes up on the display it does not cause a > > > > problem. I do not want the user to be able to see this error message > > > so > > > > I need to either fix the problem or supress error messages from > > going > > > to > > > > standard out. Any idea? > > > > > > > > Allan Wilson > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at linuxgrrls.org > > > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Mon Jun 16 13:01:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:01:52 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <002801c33437$5185ba70$4f00a8c0@Perigee.Perigeellc.com> Message-ID: On Mon, 16 Jun 2003, Shreyas Kejariwal wrote: > Hi everyone, > > On the same note, I encountered the same problem where I would see the stale > lock messages on restarting my App. I tried ,exactly what was suggested then > and now, to remove the lock files manually i.e.. rm -f /var/lock/LCK* . But > this did not help much. The problem would still occur occasionally. > Needless to say, It was hard to replicate. > > After some more digging what we found out was that we were sending data to > the serial port, say /tty/S1 without anything being connected to this port. > So it was assumed that maybe the buffer is not cleared when we release the > port from within our application. So we redesigned our App to not send data > blindly to the port. This actually worked and we no longer see the stale > lock warning. > hmm. maybe the following in Serialimp.c:nativeClose() would solve this: ENTER( "RXTXPort:nativeClose" ); if (fd > 0) { do { tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); } while ( result < 0 && ( errno == EINTR || errno == EIO ); UNLOCK( filename, pid ); } .. add a flush for input and output and also check for input/output errors during close. The flush discards data. From adamh at basis.com Mon Jun 16 13:17:17 2003 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 16 Jun 2003 13:17:17 -0600 Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: <20030616191717.GE1584@basis.com> On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > The thing that confuses me is RXTXPort.java has a finalize() which calls > close(). I'm curious about how that is being missed even if the > application/library does not close the port but is exiting normally. One thing to note is that not all finalizers are run at program termination unless you call System.runFinalizersOnExit(true). However, you might also note that the method is deprecated because of the possible deadlocks that can cause. The default is that finalizers are not run. In general, finalizers are not recommended because of all sorts of problems they cause (ill-defined thread semantics, deadlocks, unpredictability of invocation, etc). You can use the Runtime.addShutdownHook() to acheive the same goal when using Java >= 1.3... Hope that helps a little, Adam -- Go to http://pgp.mit.edu/ to get public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030616/82023dd9/attachment-0001.bin From taj at linuxgrrls.org Mon Jun 16 13:54:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 20:54:41 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <20030616191717.GE1584@basis.com> References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> <20030616191717.GE1584@basis.com> Message-ID: On Mon, 16 Jun 2003, Adam Hawthorne wrote: > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > close(). I'm curious about how that is being missed even if the > > application/library does not close the port but is exiting normally. > > One thing to note is that not all finalizers are run at program termination > unless you call System.runFinalizersOnExit(true). However, you might also > note that the method is deprecated because of the possible deadlocks that > can cause. The default is that finalizers are not run. > > In general, finalizers are not recommended because of all sorts of problems > they cause (ill-defined thread semantics, deadlocks, unpredictability of > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > same goal when using Java >= 1.3... > OK, Thanks Attached is a diff that does everything discussed except for turning off warnings. Its against rxtx-2.1-7pre16 but should fit into 2.0-5 fine. It may not be correct but does compile. It should narrow the issues considerably and should be possible to get working on the systems able to produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:10:55.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcdrain( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From taj at linuxgrrls.org Mon Jun 16 14:19:15 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 16 Jun 2003 21:19:15 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: References: <8B70AF95D496D7479193BEAC44B889FE0414F7@dh-exchg2000.data-house.com> Message-ID: Oops. That should be tcflush not tcdrain. Interesting that it compiled. Attached is the corrected patch. On Mon, 16 Jun 2003, Trent Jarvi wrote: > > > On Mon, 16 Jun 2003, Adam Hawthorne wrote: > > > On Mon, Jun 16, 2003 at 07:11:17PM +0100, Trent Jarvi wrote: > > > > > > The thing that confuses me is RXTXPort.java has a finalize() which calls > > > close(). I'm curious about how that is being missed even if the > > > application/library does not close the port but is exiting normally. > > > > One thing to note is that not all finalizers are run at program termination > > unless you call System.runFinalizersOnExit(true). However, you might also > > note that the method is deprecated because of the possible deadlocks that > > can cause. The default is that finalizers are not run. > > > > In general, finalizers are not recommended because of all sorts of problems > > they cause (ill-defined thread semantics, deadlocks, unpredictability of > > invocation, etc). You can use the Runtime.addShutdownHook() to acheive the > > same goal when using Java >= 1.3... > > > > OK, Thanks > > Attached is a diff that does everything discussed except for > turning off warnings. Its against rxtx-2.1-7pre16 but should fit into > 2.0-5 fine. > > It may not be correct but does compile. It should narrow the issues > considerably and should be possible to get working on the systems able to > produce the problem. -------------- next part -------------- diff -ur src.old/RXTXPort.java src/RXTXPort.java --- src.old/RXTXPort.java 2003-03-27 09:34:07.000000000 -0500 +++ src/RXTXPort.java 2003-06-16 15:09:33.000000000 -0400 @@ -90,6 +90,13 @@ waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} + + Runtime.getRuntime().addShutdownHook( new Thread() { + public void run() { + RXTXPort.this.finalize(); + } + } ); + timeout = -1; /* default disabled timeout */ if (debug) z.reportln( "RXTXPort:RXTXPort("+name+") returns with fd = " + diff -ur src.old/SerialImp.c src/SerialImp.c --- src.old/SerialImp.c 2003-03-27 09:38:07.000000000 -0500 +++ src/SerialImp.c 2003-06-16 15:38:25.000000000 -0400 @@ -620,8 +620,9 @@ if (fd > 0) { do { + tcflush( fd, TCIOFLUSH ); result=CLOSE (fd); - } while ( result < 0 && errno == EINTR ); + } while ( result < 0 && ( errno == EINTR || errno == EIO ) ); UNLOCK( filename, pid ); } report("nativeClose: Delete jclazz\n"); From Wayne at new-programmer.com Mon Jun 16 21:09:08 2003 From: Wayne at new-programmer.com (Wayne) Date: 16 Jun 2003 23:09:08 -0400 Subject: [Rxtx] java frustration Message-ID: <1055819348.5037.6.camel@Nikon-Linux> ok, i'm not sure what exactly is going on, but i will include a copy of what i see when i try and open a serial port in a java program i have that we use at work. one thing i can think of is that we use this java program in windows and it is written specifically for windows and not compatible with java. if this is the case, how can i change it? i really need to get this program to work with linux, but it seems i'm faced with problem after problem. output of screen when error occurs: [wayne at Nikon-Linux wayne]$ ./localscan java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, method: flush signature: ()V) Illegal use of nonvirtual function call at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at aesScan.openConnection(aesScan.java:552) at aesScan.actionPerformed(aesScan.java:677) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245) at java.awt.Component.processMouseEvent(Component.java:5134) at java.awt.Component.processEvent(Component.java:4931) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3639) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095) at java.awt.Container.dispatchEventImpl(Container.java:1609) at java.awt.Window.dispatchEventImpl(Window.java:1590) at java.awt.Component.dispatchEvent(Component.java:3480) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) From taj at linuxgrrls.org Mon Jun 16 21:25:52 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue, 17 Jun 2003 04:25:52 +0100 (BST) Subject: [Rxtx] java frustration In-Reply-To: <1055819348.5037.6.camel@Nikon-Linux> References: <1055819348.5037.6.camel@Nikon-Linux> Message-ID: On Tue, 16 Jun 2003, Wayne wrote: > ok, i'm not sure what exactly is going on, but i will include a copy of > what i see when i try and open a serial port in a java program i have > that we use at work. one thing i can think of is that we use this java > program in windows and it is written specifically for windows and not > compatible with java. if this is the case, how can i change it? i > really need to get this program to work with linux, but it seems i'm > faced with problem after problem. > > output of screen when error occurs: > > [wayne at Nikon-Linux wayne]$ ./localscan > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > method: flush signature: ()V) Illegal use of nonvirtual function call [snip] Java 1.3 caught rxtx using bad practice. It was not a serious error but was wrong. You can either upgrade rxtx which has the code changes to get past this error or run java with: java -noverify I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. I think the problem was private rather than protected methods being called from inner classes. -- not so interesting :) From rkannan at govpx.com Mon Jun 16 21:30:25 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 16 Jun 2003 23:30:25 -0400 Subject: [Rxtx] java frustration In-Reply-To: References: <1055819348.5037.6.camel@Nikon-Linux> <1055819348.5037.6.camel@Nikon-Linux> Message-ID: <4.3.2.7.2.20030616232930.019f2a68@mail1.govpx.com> I got this error on java 1.4 but may be using old code and got past the error with -noverify option works well At 04:25 AM 6/17/2003 +0100, you wrote: >On Tue, 16 Jun 2003, Wayne wrote: > > > ok, i'm not sure what exactly is going on, but i will include a copy of > > what i see when i try and open a serial port in a java program i have > > that we use at work. one thing i can think of is that we use this java > > program in windows and it is written specifically for windows and not > > compatible with java. if this is the case, how can i change it? i > > really need to get this program to work with linux, but it seems i'm > > faced with problem after problem. > > > > output of screen when error occurs: > > > > [wayne at Nikon-Linux wayne]$ ./localscan > > java.lang.VerifyError: (class: gnu/io/RXTXPort$SerialOutputStream, > > method: flush signature: ()V) Illegal use of nonvirtual function call >[snip] > >Java 1.3 caught rxtx using bad practice. It was not a serious error but >was wrong. You can either upgrade rxtx which has the code changes to get >past this error or run java with: > > java -noverify > >I suspect you are using rxtx 1.3 or 1.4 which is fairly dated. > >I think the problem was private rather than protected methods being called >from inner classes. > >-- not so interesting :) >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at parcelfarce.linux.theplanet.co.uk Tue Jun 17 15:58:49 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Tue, 17 Jun 2003 22:58:49 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support (fwd) Message-ID: Hi Paul I did look into RS485 support in rxtx over RS232 ports. After discussions with others that had tried it, the conclusion was that the best way to do this was to purchase inexpensive hardware converters. The main problem is timing which is kernel dependand and not very controllable in userland. That said I did not test the driver. If you look at the native C driver, I do try to do things right but depending upon what control lines you are using, it may not be right for you. If you have further questions, regarding the driver and would like to look at further support, I encourage you to join the rxtx mail list. I'll gladly look back at the src and try to help. Remember that timing may be the main problem. I prefer the mail list because it leave a record other people like you may search. On Tue, 17 Jun 2003 Paul.Fazio at apcc.com wrote: > Hello, > > I noticed on your home page under the date Mar 12 2000 you list rough > framework for RS485 support as one of the new features. I have version > 2.1-6 and am unable to communicate via my RS-485 port. I am not sure if it > is a hardware issue or a software issue. Have you done much testing of the > RS485 support? I am just trying to rule out the driver as one possible > cause of the communication issue. > > Thank you, > Paul Fazio > > > -- Trent Jarvi taj at www.linux.org.uk From jasmine at regolith.co.uk Wed Jun 18 10:12:32 2003 From: jasmine at regolith.co.uk (jasmine@regolith.co.uk) Date: Wed, 18 Jun 2003 17:12:32 +0100 (BST) Subject: [Rxtx] Testing Message-ID: ....yet another server move. Hello? -J. From taj at linuxgrrls.org Mon Jun 23 01:01:03 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 23 Jun 2003 08:01:03 +0100 (BST) Subject: [Rxtx] Test post. Message-ID: I'm just testing if our signature is correct. The servers have been moved around a bit. From jasmine at regolith.co.uk Mon Jun 23 01:15:19 2003 From: jasmine at regolith.co.uk (Jasmine Strong) Date: Mon, 23 Jun 2003 08:15:19 +0100 Subject: [Rxtx] Test post. In-Reply-To: Message-ID: <7232B425-A54A-11D7-98AE-000393AD6294@regolith.co.uk> On Monday, Jun 23, 2003, at 08:01 Europe/London, Trent Jarvi wrote: > > I'm just testing if our signature is correct. The servers have been > moved > around a bit. Yeah, sorry about that. For information, everything is now stable and we shouldn't have to change anything for a while. -J, friendly local bat-admin From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 02:23:22 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 09:23:22 +0100 (BST) Subject: [Rxtx] Re: serial pb ? In-Reply-To: Message-ID: Hi, I would need to know which OS and what version of rxtx are being used. Looking at a current copy I see code like the following which suggests we have looked at space parity. With rxtx 2.1-7pre16 you will not see the specific message you mentioned. My guess is either your hardware driver is not supporting CMSPAR (On W32 it my just be a bug on my part) or you have a version of rxtx with a bug in the following code. int translate_parity( JNIEnv *env, tcflag_t *cflag, jint parity ) { ... #ifdef CMSPAR case JPARITY_MARK: (*cflag) |= PARENB | PARODD | CMSPAR; LEAVE( "translate_parity" ); return 0; case JPARITY_SPACE: (*cflag) |= PARENB | CMSPAR; LEAVE( "translate_parity" ); return 0; #endif /* CMSPAR */ default: printf("Parity missed %i\n", (int) parity ); } LEAVE( "translate_parity" ); /* For some reason the native exceptions are not being caught. Moving this to the Java side fixed the issue. taj. throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, "", "parity value not supported" ); */ return 1; } On Tue, 24 Jun 2003 root at wass.homelinux.net wrote: > Hi, > > I am afraid I do not understand your problem. Apparently there is some > kind of problem when you try to use "PARITY_SPACE", but you don't want to > use "PARITY_SPACE", you want to use "PARITY_NONE" but "PARITY_NONE" > doesn't do anything? I am not sure what kind of hardware you are trying > to talk to through a serial port. I don't know what the serial protocol > or the pinout (if different from standard RS-232 or RS-422) of your device > is. Your problem may not even be on the software side. Your problem > could range anywhere from an incorrect pinout to a software > configuration problem. > > I'm afraid that debugging serial port issues is often very complicated > even in person... trying to debug such an issue through email is beyond my > capabilities. Sometimes the best way to debug such issues is to use an > oscilloscope and/or a null modem cable hooked to another computer. > > Now, if you have specific problems with the RXTX package, you'll have to > talk to Trent Jarvi (www.rxtx.org). Trent, not I, is the author of the > RXTX package. I just wrote a how-to for installing it. > > Sorry I couldn't be of more help. > > Thanks, > > Wade > > On Tue, 24 Jun 2003, [iso-8859-1] hugues103 wrote: > > > Hi, > > > > Maybe you can help me again : I still have a problem to communicate on the serial port. > > When I set the serial port parameters, if I choose "PARITY_SPACE", the automation > > system understand the question but I have an exception : "parity value not supported in > > RXTXPort.native.SetSerialPortParams....". If I choose "PARITY_NONE" (and I should do > > that) I have no exception but the system doesn't undestand the question... > > > > Thanks for your help if you have any idea, > > > > Bye, > > Hugues. > > > > ------------------------------------------ > > > > Faites un voeu et puis Voila ! www.voila.fr > > > > > > > > > > -- Trent Jarvi taj at www.linux.org.uk From taj at parcelfarce.linux.theplanet.co.uk Wed Jun 25 03:08:41 2003 From: taj at parcelfarce.linux.theplanet.co.uk (taj@parcelfarce.linux.theplanet.co.uk) Date: Wed, 25 Jun 2003 10:08:41 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support Message-ID: > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk From ricardo.trindade at emation.pt Wed Jun 25 03:15:05 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Wed, 25 Jun 2003 10:15:05 +0100 Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: Message-ID: Don't be so happy. Writting always works, reading will be the tricky part. What kind of 485 hardware are you using ? -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de taj at parcelfarce.linux.theplanet.co.uk Enviada: quarta-feira, 25 de Junho de 2003 10:09 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] Re: RXTXComm RS485 support > > Thanks for the information. I have enabled RS485 support and I am able to > send data, but I am unable to receive data. I was wondering if you might > have any ideas? > Ah! So the write appears to work when RS485 is enabled. This is good news. How do you try to read? Are you polling the port for data? Are you recieving the data available events? All of the reads should end up in RS485Imp.c: int read_byte_array( int fd, unsigned char *buffer, int length, int timeout ) The function is fairly small and can be tracked down to what is failing with some printfs. I'd just be guessing without more information. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Wed Jun 25 03:31:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 25 Jun 2003 10:31:07 +0100 (BST) Subject: [Rxtx] Re: RXTXComm RS485 support In-Reply-To: References: Message-ID: Hi Ricardo, Let me bring Paul (cc'd) into the discussion. He is doing the testing. On Wed, 25 Jun 2003, Ricardo Trindade wrote: > Don't be so happy. Writting always works, reading will be the tricky part. > What kind of 485 hardware are you using ? > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de taj at parcelfarce.linux.theplanet.co.uk > Enviada: quarta-feira, 25 de Junho de 2003 10:09 > Para: rxtx at linuxgrrls.org > Assunto: [Rxtx] Re: RXTXComm RS485 support > > > > > > > Thanks for the information. I have enabled RS485 support and I am able to > > send data, but I am unable to receive data. I was wondering if you might > > have any ideas? > > > > Ah! So the write appears to work when RS485 is enabled. This is good > news. How do you try to read? Are you polling the port for data? Are > you recieving the data available events? > > All of the reads should end up in RS485Imp.c: > > int read_byte_array( int fd, unsigned char *buffer, int length, > int timeout ) > > The function is fairly small and can be tracked down to what is failing > with some printfs. > > I'd just be guessing without more information. > > -- > Trent Jarvi > taj at www.linux.org.uk > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From smol at students.zcu.cz Thu Jun 26 12:30:04 2003 From: smol at students.zcu.cz (Robert Smol) Date: Thu, 26 Jun 2003 20:30:04 +0200 (CEST) Subject: [Rxtx] Crash in 1.4.1_02 Message-ID: Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked with previous version of rxtx well. But I need to set MARK and SPACE parity in my application (previous version I used didn't supported it). When started with rxtx-2.1.7-pre16 it crash exatly the same. But this happens on Debian, my gentooBox works well. Can this help? I need to fix this very soon, otherwise my boss kill me :) thank you very much Robert Smol -------------- next part -------------- kingsrv11:/opt# java SimpleRead nn Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4C378A1A Function=Java_gnu_io_RXTXCommDriver_testRead+0x21A Library=/opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Current Java thread: at gnu.io.RXTXCommDriver.testRead(Native Method) at gnu.io.RXTXCommDriver.registerValidPorts(RXTXCommDriver.java:246) at gnu.io.RXTXCommDriver.registerScannedPorts(RXTXCommDriver.java:746) at gnu.io.RXTXCommDriver.initialize(RXTXCommDriver.java:302) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:68) at SimpleRead.main(SimpleRead.java:68) Dynamic libraries: 08048000-0804e000 r-xp 00000000 08:02 79804 /opt/j2sdk/bin/java 0804e000-0804f000 rw-p 00005000 08:02 79804 /opt/j2sdk/bin/java 40000000-40011000 r-xp 00000000 08:02 159505 /lib/ld-2.3.1.so 40011000-40012000 rw-p 00011000 08:02 159505 /lib/ld-2.3.1.so 40012000-40015000 r--s 00000000 08:02 159922 /opt/j2sdk/jre/lib/ext/dnsns.jar 40016000-40022000 r-xp 00000000 08:02 159761 /lib/libpthread-0.10.so 40022000-40025000 rw-p 0000c000 08:02 159761 /lib/libpthread-0.10.so 40065000-40067000 r-xp 00000000 08:02 159735 /lib/libdl-2.3.1.so 40067000-40068000 rw-p 00001000 08:02 159735 /lib/libdl-2.3.1.so 40068000-40170000 r-xp 00000000 08:02 159733 /lib/libc-2.3.1.so 40170000-40176000 rw-p 00107000 08:02 159733 /lib/libc-2.3.1.so 40178000-40490000 r-xp 00000000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40490000-40644000 rw-p 00317000 08:02 302889 /opt/j2sdk/jre/lib/i386/client/libjvm.so 40654000-40664000 r-xp 00000000 08:02 159737 /lib/libnsl-2.3.1.so 40664000-40665000 rw-p 00010000 08:02 159737 /lib/libnsl-2.3.1.so 40667000-40687000 r-xp 00000000 08:02 159736 /lib/libm-2.3.1.so 40687000-40688000 rw-p 0001f000 08:02 159736 /lib/libm-2.3.1.so 40688000-40691000 r-xp 00000000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40691000-40692000 rw-p 00008000 08:02 127764 /opt/j2sdk/jre/lib/i386/native_threads/libhpi.so 40693000-406a3000 r-xp 00000000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a3000-406a5000 rw-p 0000f000 08:02 127770 /opt/j2sdk/jre/lib/i386/libverify.so 406a5000-406c6000 r-xp 00000000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c6000-406c8000 rw-p 00020000 08:02 127771 /opt/j2sdk/jre/lib/i386/libjava.so406c8000-406dd000 r-xp 00000000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406dd000-406df000 rw-p 00014000 08:02 127773 /opt/j2sdk/jre/lib/i386/libzip.so 406df000-41dad000 r--s 00000000 08:02 127896 /opt/j2sdk/jre/lib/rt.jar 41df0000-41e07000 r--s 00000000 08:02 127794 /opt/j2sdk/jre/lib/sunrsasign.jar 41e07000-41e78000 r--s 00000000 08:02 127796 /opt/j2sdk/jre/lib/jsse.jar 41e78000-41e8b000 r--s 00000000 08:02 127795 /opt/j2sdk/jre/lib/jce.jar 41e8b000-42147000 r--s 00000000 08:02 127894 /opt/j2sdk/jre/lib/charsets.jar 4c270000-4c279000 r-xp 00000000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c279000-4c27a000 rw-p 00009000 08:02 159738 /lib/libnss_compat-2.3.1.so 4c27a000-4c297000 r--s 00000000 08:02 159921 /opt/j2sdk/jre/lib/ext/sunjce_provider.jar 4c297000-4c336000 r--s 00000000 08:02 159923 /opt/j2sdk/jre/lib/ext/localedata.jar 4c336000-4c344000 r--s 00000000 08:02 159924 /opt/j2sdk/jre/lib/ext/ldapsec.jar4c344000-4c363000 r--s 00000000 08:02 334810 /opt/j2sdk/jre/lib/ext/mysql-connector-java-2.0.14-bin.jar 4c363000-4c372000 r--s 00000000 08:02 161456 /opt/j2sdk/jre/lib/ext/RXTXcomm.jar 4c372000-4c37c000 r-xp 00000000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so 4c37c000-4c37d000 rw-p 00009000 08:02 129657 /opt/j2sdk/jre/lib/i386/librxtxSerial-2.1-7pre16.so Local Time = Thu Jun 26 19:53:15 2003 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid10352.log. # Please refer to the file for further information. # Aborted kingsrv11:/opt# -------------- next part -------------- /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; //import javax.comm.*; import gnu.io.*; /** * Class declaration * * * @author * @version 1.8, 08/03/00 */ public class SimpleRead implements Runnable, SerialPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; SerialPort serialPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "/dev/ttyS0"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println(portId.getName()); if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } /** * Constructor declaration * * * @see */ public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = serialPort.getInputStream(); } catch (IOException e) {} try { serialPort.addEventListener(this); } catch (TooManyListenersException e) {} serialPort.notifyOnDataAvailable(true); try { serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); } catch (UnsupportedCommOperationException e) {} readThread = new Thread(this); readThread.start(); } /** * Method declaration * * * @see */ public void run() { try { Thread.sleep(20000); } catch (InterruptedException e) {} } /** * Method declaration * * * @param event * * @see */ public void serialEvent(SerialPortEvent event) { switch (event.getEventType()) { case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: byte[] readBuffer = new byte[20]; try { while (inputStream.available() > 0) { int numBytes = inputStream.read(readBuffer); } System.out.print(new String(readBuffer)); } catch (IOException e) {} break; } } } From taj at linuxgrrls.org Thu Jun 26 17:57:35 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 00:57:35 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2003, Robert Smol wrote: > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > with previous version of rxtx well. But I need to set MARK and SPACE > parity in my application (previous version I used didn't supported it). > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > happens on Debian, my gentooBox works well. Can this help? I need to fix > this very soon, otherwise my boss kill me :) > I've just added a couple println's around the port enumeration in the example. testRead() is used during enumeration. + System.out.println("Enumerating ports"); portList = CommPortIdentifier.getPortIdentifiers(); + System.out.println("Enumerated ports"); java SimpleRead Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 ... waiting for input. There is nothing connected to the port, but that should not matter in this case. This is a redhat 8.0 system: glibc-2.2.93-5 kernel 2.4.18-14 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) rxtx-2.1-7pre16 default configure options. This also happens to be the system the binaries offered for pre16 are built on. testRead() should not be causing sig11's (memory corruption). I guess my questions are 1) What are the glibc versions that work and don't work for you? 2) Are you building rxtx on each system? If not, does that help? If I had to guess, I suspect a glibc related glitch. From taj at linuxgrrls.org Thu Jun 26 19:28:51 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:28:51 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > with previous version of rxtx well. But I need to set MARK and SPACE > > parity in my application (previous version I used didn't supported it). > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > this very soon, otherwise my boss kill me :) > > > > I've just added a couple println's around the port enumeration in the > example. testRead() is used during enumeration. > > + System.out.println("Enumerating ports"); > portList = CommPortIdentifier.getPortIdentifiers(); > + System.out.println("Enumerated ports"); > > > java SimpleRead > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > ... waiting for input. > > There is nothing connected to the port, but that should not matter in this > case. > > This is a redhat 8.0 system: > > glibc-2.2.93-5 > kernel 2.4.18-14 > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > rxtx-2.1-7pre16 default configure options. > > This also happens to be the system the binaries offered for pre16 are > built on. > > testRead() should not be causing sig11's (memory corruption). > > I guess my questions are > > 1) What are the glibc versions that work and don't work for you? > 2) Are you building rxtx on each system? If not, does that help? > > If I had to guess, I suspect a glibc related glitch. > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has bundled it with a bunch of 'stuff.' This is the same machine mentioned above. [] $ java -version && java SimpleRead java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 From taj at linuxgrrls.org Thu Jun 26 19:49:13 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 02:49:13 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > > > > > On Thu, 26 Jun 2003, Robert Smol wrote: > > > > > Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it worked > > > with previous version of rxtx well. But I need to set MARK and SPACE > > > parity in my application (previous version I used didn't supported it). > > > When started with rxtx-2.1.7-pre16 it crash exatly the same. But this > > > happens on Debian, my gentooBox works well. Can this help? I need to fix > > > this very soon, otherwise my boss kill me :) > > > > > > > I've just added a couple println's around the port enumeration in the > > example. testRead() is used during enumeration. > > > > + System.out.println("Enumerating ports"); > > portList = CommPortIdentifier.getPortIdentifiers(); > > + System.out.println("Enumerated ports"); > > > > > > java SimpleRead > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > ... waiting for input. > > > > There is nothing connected to the port, but that should not matter in this > > case. > > > > This is a redhat 8.0 system: > > > > glibc-2.2.93-5 > > kernel 2.4.18-14 > > Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > > rxtx-2.1-7pre16 default configure options. > > > > This also happens to be the system the binaries offered for pre16 are > > built on. > > > > testRead() should not be causing sig11's (memory corruption). > > > > I guess my questions are > > > > 1) What are the glibc versions that work and don't work for you? > > 2) Are you building rxtx on each system? If not, does that help? > > > > If I had to guess, I suspect a glibc related glitch. > > > > > > One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > bundled it with a bunch of 'stuff.' > > This is the same machine mentioned above. > > [] $ java -version && java SimpleRead > java version "1.4.2" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > [] $ java -version && java SimpleRead java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Enumerating ports Devel Library ========================================= Native lib Version = RXTX-2.1-7pre16 Java lib Version = RXTX-2.1-7pre16 Enumerated ports /dev/ttyS0 Found port: /dev/ttyS0 /dev/ttyS1 So that is 3 data points of 1.4 that are known to work including the version you tried. I would strongly suspect this is a glibc issue. You could drop to jdk 1.3, upgrade glibc to known good or wait for patches to filter into the distros that dont work. I seriously doubt much can be done from rxtx other than trying recompiling on the trouble platforms (Its fixed things like this before). From moritz.gmelin at gmx.de Thu Jun 26 23:02:50 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 07:02:50 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Hi you both, since the same trouble appears in Windows (XP)-Environments too. Can it still be a glibc Problem ? I had no trouble myself with my XP-Box in the office. But a customer of mine had nothing but crashes on his. although we both hat XP-SP1 installed. I belive I had no Problems on either Linux or MacOS X. M. Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> >> >> On Fri, 27 Jun 2003, Trent Jarvi wrote: >> >>> >>> >>> On Thu, 26 Jun 2003, Robert Smol wrote: >>> >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>> worked >>>> with previous version of rxtx well. But I need to set MARK and SPACE >>>> parity in my application (previous version I used didn't supported >>>> it). >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>> this >>>> happens on Debian, my gentooBox works well. Can this help? I need >>>> to fix >>>> this very soon, otherwise my boss kill me :) >>>> >>> >>> I've just added a couple println's around the port enumeration in the >>> example. testRead() is used during enumeration. >>> >>> + System.out.println("Enumerating ports"); >>> portList = CommPortIdentifier.getPortIdentifiers(); >>> + System.out.println("Enumerated ports"); >>> >>> >>> java SimpleRead >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> ... waiting for input. >>> >>> There is nothing connected to the port, but that should not matter >>> in this >>> case. >>> >>> This is a redhat 8.0 system: >>> >>> glibc-2.2.93-5 >>> kernel 2.4.18-14 >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>> rxtx-2.1-7pre16 default configure options. >>> >>> This also happens to be the system the binaries offered for pre16 are >>> built on. >>> >>> testRead() should not be causing sig11's (memory corruption). >>> >>> I guess my questions are >>> >>> 1) What are the glibc versions that work and don't work for you? >>> 2) Are you building rxtx on each system? If not, does that help? >>> >>> If I had to guess, I suspect a glibc related glitch. >>> >>> >> >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has >> bundled it with a bunch of 'stuff.' >> >> This is the same machine mentioned above. >> >> [] $ java -version && java SimpleRead >> java version "1.4.2" >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >> Enumerating ports >> Devel Library >> ========================================= >> Native lib Version = RXTX-2.1-7pre16 >> Java lib Version = RXTX-2.1-7pre16 >> Enumerated ports >> /dev/ttyS0 >> Found port: /dev/ttyS0 >> /dev/ttyS1 >> > > [] $ java -version && java SimpleRead > java version "1.4.1_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > Enumerating ports > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre16 > Java lib Version = RXTX-2.1-7pre16 > Enumerated ports > /dev/ttyS0 > Found port: /dev/ttyS0 > /dev/ttyS1 > > > So that is 3 data points of 1.4 that are known to work including the > version you tried. I would strongly suspect this is a glibc issue. > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > patches > to filter into the distros that dont work. I seriously doubt much can > be > done from rxtx other than trying recompiling on the trouble platforms > (Its > fixed things like this before). > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:21:56 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:21:56 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> References: <9A4870A6-A85C-11D7-8040-000393719396@gmx.de> Message-ID: Dang.. XP eliminates 80% of the code involved (lock files). It was testRead() that showed in the trace? But w32 is adding a POSIX like layer... I wouldnt say the problems are the same yet. This is interesting though. I can suggest XP sp1 is tested even more than Linux by some. Well that may be an understatment. Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 binaries. There is a known issue that can show up after 3+ hours of intense testing on w32-nt types we are looking at but this would be new. I dont think production systems on nice companies helping rxtx behind the scenes have moved to the 1.4 jre though things are being worked out. I tried to suggest not using 1.4 for this reason when the issue first popped up. I'm not sure what is going on yet. Lets start gathering the evidence so it can be reproduced. w32xp with which rxtx and which jre? We need to know how to reproduce the problem in Linux too. As far as I can tell that is still a glibc issue. This list is the only place I've heard of this problem. Not that that should be a shock. The use will vary wildly here. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Hi you both, > > since the same trouble appears in Windows (XP)-Environments too. Can it > still be a glibc Problem ? > I had no trouble myself with my XP-Box in the office. But a customer of > mine had nothing but crashes on his. although we both hat XP-SP1 > installed. I belive I had no Problems on either Linux or MacOS X. > > M. > > Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > > > On Fri, 27 Jun 2003, Trent Jarvi wrote: > > > >> > >> > >> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >> > >>> > >>> > >>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>> > >>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>> worked > >>>> with previous version of rxtx well. But I need to set MARK and SPACE > >>>> parity in my application (previous version I used didn't supported > >>>> it). > >>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>> this > >>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>> to fix > >>>> this very soon, otherwise my boss kill me :) > >>>> > >>> > >>> I've just added a couple println's around the port enumeration in the > >>> example. testRead() is used during enumeration. > >>> > >>> + System.out.println("Enumerating ports"); > >>> portList = CommPortIdentifier.getPortIdentifiers(); > >>> + System.out.println("Enumerated ports"); > >>> > >>> > >>> java SimpleRead > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> ... waiting for input. > >>> > >>> There is nothing connected to the port, but that should not matter > >>> in this > >>> case. > >>> > >>> This is a redhat 8.0 system: > >>> > >>> glibc-2.2.93-5 > >>> kernel 2.4.18-14 > >>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>> rxtx-2.1-7pre16 default configure options. > >>> > >>> This also happens to be the system the binaries offered for pre16 are > >>> built on. > >>> > >>> testRead() should not be causing sig11's (memory corruption). > >>> > >>> I guess my questions are > >>> > >>> 1) What are the glibc versions that work and don't work for you? > >>> 2) Are you building rxtx on each system? If not, does that help? > >>> > >>> If I had to guess, I suspect a glibc related glitch. > >>> > >>> > >> > >> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun has > >> bundled it with a bunch of 'stuff.' > >> > >> This is the same machine mentioned above. > >> > >> [] $ java -version && java SimpleRead > >> java version "1.4.2" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >> Enumerating ports > >> Devel Library > >> ========================================= > >> Native lib Version = RXTX-2.1-7pre16 > >> Java lib Version = RXTX-2.1-7pre16 > >> Enumerated ports > >> /dev/ttyS0 > >> Found port: /dev/ttyS0 > >> /dev/ttyS1 > >> > > > > [] $ java -version && java SimpleRead > > java version "1.4.1_02" > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > > Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > > Enumerating ports > > Devel Library > > ========================================= > > Native lib Version = RXTX-2.1-7pre16 > > Java lib Version = RXTX-2.1-7pre16 > > Enumerated ports > > /dev/ttyS0 > > Found port: /dev/ttyS0 > > /dev/ttyS1 > > > > > > So that is 3 data points of 1.4 that are known to work including the > > version you tried. I would strongly suspect this is a glibc issue. > > > > You could drop to jdk 1.3, upgrade glibc to known good or wait for > > patches > > to filter into the distros that dont work. I seriously doubt much can > > be > > done from rxtx other than trying recompiling on the trouble platforms > > (Its > > fixed things like this before). > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Thu Jun 26 23:37:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 06:37:07 +0100 (BST) Subject: [Rxtx] w32 Blowing up during enumeration [vmware] Message-ID: This may not be related to the thread concering testRead() but I'm sure someone will see it eventually. Rxtx will blow up silly bad in w32 under vmware. If you _ever_ decide to do this, #define TRENT_IS_HERE_DEBUGGING_ENUMERATION in SerialImp.c. The basic problem is vmware lies about ports and then crashes on an eventual irq conflict. The define just pokes COM1 and COM2. If you have COM1 and COM3 is probed the irq conflict shows up. That may trigger some memories from w32 programmers. Generally vmware works very well for testing serial comm in w32 but you dont ever want to figure that one out. From taj at linuxgrrls.org Fri Jun 27 00:12:07 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:12:07 +0100 (BST) Subject: [Rxtx] rxtx 2.0 release? Message-ID: I think most have noticed that most of the development is going on in 2.1. Things are not going fast mainly because we are tracking down bugs that would normally be silly corner cases. But we are looking at them. And then things show up on the mail list you don't expect at all :) But I want to open up the question about rxtx 2.0. There is no intention of dropping rxtx 2.0 but the intention was to release it when the rxtx 2.1 pre releases ran out of RS232 bugs. They are drying up. There is one more tricky bug to find on w32 as far as I know. I've said tht before. rxtx 2.0 is mainly neglected because there are manweeks of Q&A being put into 2.1. The assumption is the fixes will be moved to 2.0. I'm also with the feeling that most people using 2.0 want linux or mac os x which appears to be working well. The Q&A has only turned up a couple bugs in linux. We don't have formal testing in mac os x yet. I would be very much in favor of helping someone do rxtx 2.0 releases in a more timely fashion. If there is a need, there will probably be a volunteer. Otherwise, in response to an email off the list, there is no plan to end rxtx 2.0. I've not seen a tremendous need and honestly its hard enough to solve bugs and get the prereleases out. rxtx 2.1-7 will not be formally released with out a formal 2.0. But at the same time I would not use rxtx 2.0 for solaris or w32 right now. Go with sun's solution if you want to do that. If thats not enough, you may want to look at rxtx 2.1 prereleases. From moritz.gmelin at gmx.de Fri Jun 27 00:21:46 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:21:46 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: Well, it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while the other didn't. I had to move the stuff back to suns comm-libs for the thing to be productive. It works with no problems there. M. Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang.. XP eliminates 80% of the code involved (lock files). It was > testRead() that showed in the trace? But w32 is adding a POSIX like > layer... > > I wouldnt say the problems are the same yet. This is interesting > though. > I can suggest XP sp1 is tested even more than Linux by some. Well that > may be an understatment. > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > binaries. There is a known issue that can show up after 3+ hours of > intense testing on w32-nt types we are looking at but this would be > new. > > I dont think production systems on nice companies helping rxtx behind > the > scenes have moved to the 1.4 jre though things are being worked out. I > tried to suggest not using 1.4 for this reason when the issue first > popped > up. > > I'm not sure what is going on yet. Lets start gathering the evidence > so > it can be reproduced. w32xp with which rxtx and which jre? > > We need to know how to reproduce the problem in Linux too. As far as I > can tell that is still a glibc issue. > > This list is the only place I've heard of this problem. Not that that > should be a shock. The use will vary wildly here. > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Hi you both, >> >> since the same trouble appears in Windows (XP)-Environments too. Can >> it >> still be a glibc Problem ? >> I had no trouble myself with my XP-Box in the office. But a customer >> of >> mine had nothing but crashes on his. although we both hat XP-SP1 >> installed. I belive I had no Problems on either Linux or MacOS X. >> >> M. >> >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>> >>>> >>>> >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>> >>>>> >>>>> >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>> >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it >>>>>> worked >>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>> SPACE >>>>>> parity in my application (previous version I used didn't supported >>>>>> it). >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>> this >>>>>> happens on Debian, my gentooBox works well. Can this help? I need >>>>>> to fix >>>>>> this very soon, otherwise my boss kill me :) >>>>>> >>>>> >>>>> I've just added a couple println's around the port enumeration in >>>>> the >>>>> example. testRead() is used during enumeration. >>>>> >>>>> + System.out.println("Enumerating ports"); >>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>> + System.out.println("Enumerated ports"); >>>>> >>>>> >>>>> java SimpleRead >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> ... waiting for input. >>>>> >>>>> There is nothing connected to the port, but that should not matter >>>>> in this >>>>> case. >>>>> >>>>> This is a redhat 8.0 system: >>>>> >>>>> glibc-2.2.93-5 >>>>> kernel 2.4.18-14 >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>> rxtx-2.1-7pre16 default configure options. >>>>> >>>>> This also happens to be the system the binaries offered for pre16 >>>>> are >>>>> built on. >>>>> >>>>> testRead() should not be causing sig11's (memory corruption). >>>>> >>>>> I guess my questions are >>>>> >>>>> 1) What are the glibc versions that work and don't work for you? >>>>> 2) Are you building rxtx on each system? If not, does that help? >>>>> >>>>> If I had to guess, I suspect a glibc related glitch. >>>>> >>>>> >>>> >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>> has >>>> bundled it with a bunch of 'stuff.' >>>> >>>> This is the same machine mentioned above. >>>> >>>> [] $ java -version && java SimpleRead >>>> java version "1.4.2" >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>> Enumerating ports >>>> Devel Library >>>> ========================================= >>>> Native lib Version = RXTX-2.1-7pre16 >>>> Java lib Version = RXTX-2.1-7pre16 >>>> Enumerated ports >>>> /dev/ttyS0 >>>> Found port: /dev/ttyS0 >>>> /dev/ttyS1 >>>> >>> >>> [] $ java -version && java SimpleRead >>> java version "1.4.1_02" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>> Enumerating ports >>> Devel Library >>> ========================================= >>> Native lib Version = RXTX-2.1-7pre16 >>> Java lib Version = RXTX-2.1-7pre16 >>> Enumerated ports >>> /dev/ttyS0 >>> Found port: /dev/ttyS0 >>> /dev/ttyS1 >>> >>> >>> So that is 3 data points of 1.4 that are known to work including the >>> version you tried. I would strongly suspect this is a glibc issue. >>> >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>> patches >>> to filter into the distros that dont work. I seriously doubt much >>> can >>> be >>> done from rxtx other than trying recompiling on the trouble platforms >>> (Its >>> fixed things like this before). >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 00:31:12 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 07:31:12 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: References: Message-ID: Dang Moritz. You've 'got me in a bad spot' :) It is crashing on one machine and working on basically an identical machine? This was rxtx 2.1-7pre16? Could you find anything different? Maybe he somehow used msft's jre? Maybe the port configuration was different? Anything? Do you have a stack dump? On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Well, > > it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > the other didn't. I had to move the stuff back to suns comm-libs for > the thing to be productive. It works with no problems there. > > M. > > > Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang.. XP eliminates 80% of the code involved (lock files). It was > > testRead() that showed in the trace? But w32 is adding a POSIX like > > layer... > > > > I wouldnt say the problems are the same yet. This is interesting > > though. > > I can suggest XP sp1 is tested even more than Linux by some. Well that > > may be an understatment. > > > > Was this rxtx 2.1? We have hundreds of hours of testing on those pre16 > > binaries. There is a known issue that can show up after 3+ hours of > > intense testing on w32-nt types we are looking at but this would be > > new. > > > > I dont think production systems on nice companies helping rxtx behind > > the > > scenes have moved to the 1.4 jre though things are being worked out. I > > tried to suggest not using 1.4 for this reason when the issue first > > popped > > up. > > > > I'm not sure what is going on yet. Lets start gathering the evidence > > so > > it can be reproduced. w32xp with which rxtx and which jre? > > > > We need to know how to reproduce the problem in Linux too. As far as I > > can tell that is still a glibc issue. > > > > This list is the only place I've heard of this problem. Not that that > > should be a shock. The use will vary wildly here. > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Hi you both, > >> > >> since the same trouble appears in Windows (XP)-Environments too. Can > >> it > >> still be a glibc Problem ? > >> I had no trouble myself with my XP-Box in the office. But a customer > >> of > >> mine had nothing but crashes on his. although we both hat XP-SP1 > >> installed. I belive I had no Problems on either Linux or MacOS X. > >> > >> M. > >> > >> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> > >>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>> > >>>> > >>>> > >>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>> > >>>>> > >>>>> > >>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>> > >>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think it > >>>>>> worked > >>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>> SPACE > >>>>>> parity in my application (previous version I used didn't supported > >>>>>> it). > >>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>> this > >>>>>> happens on Debian, my gentooBox works well. Can this help? I need > >>>>>> to fix > >>>>>> this very soon, otherwise my boss kill me :) > >>>>>> > >>>>> > >>>>> I've just added a couple println's around the port enumeration in > >>>>> the > >>>>> example. testRead() is used during enumeration. > >>>>> > >>>>> + System.out.println("Enumerating ports"); > >>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>> + System.out.println("Enumerated ports"); > >>>>> > >>>>> > >>>>> java SimpleRead > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> ... waiting for input. > >>>>> > >>>>> There is nothing connected to the port, but that should not matter > >>>>> in this > >>>>> case. > >>>>> > >>>>> This is a redhat 8.0 system: > >>>>> > >>>>> glibc-2.2.93-5 > >>>>> kernel 2.4.18-14 > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>> rxtx-2.1-7pre16 default configure options. > >>>>> > >>>>> This also happens to be the system the binaries offered for pre16 > >>>>> are > >>>>> built on. > >>>>> > >>>>> testRead() should not be causing sig11's (memory corruption). > >>>>> > >>>>> I guess my questions are > >>>>> > >>>>> 1) What are the glibc versions that work and don't work for you? > >>>>> 2) Are you building rxtx on each system? If not, does that help? > >>>>> > >>>>> If I had to guess, I suspect a glibc related glitch. > >>>>> > >>>>> > >>>> > >>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>> has > >>>> bundled it with a bunch of 'stuff.' > >>>> > >>>> This is the same machine mentioned above. > >>>> > >>>> [] $ java -version && java SimpleRead > >>>> java version "1.4.2" > >>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>> Enumerating ports > >>>> Devel Library > >>>> ========================================= > >>>> Native lib Version = RXTX-2.1-7pre16 > >>>> Java lib Version = RXTX-2.1-7pre16 > >>>> Enumerated ports > >>>> /dev/ttyS0 > >>>> Found port: /dev/ttyS0 > >>>> /dev/ttyS1 > >>>> > >>> > >>> [] $ java -version && java SimpleRead > >>> java version "1.4.1_02" > >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) > >>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>> Enumerating ports > >>> Devel Library > >>> ========================================= > >>> Native lib Version = RXTX-2.1-7pre16 > >>> Java lib Version = RXTX-2.1-7pre16 > >>> Enumerated ports > >>> /dev/ttyS0 > >>> Found port: /dev/ttyS0 > >>> /dev/ttyS1 > >>> > >>> > >>> So that is 3 data points of 1.4 that are known to work including the > >>> version you tried. I would strongly suspect this is a glibc issue. > >>> > >>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>> patches > >>> to filter into the distros that dont work. I seriously doubt much > >>> can > >>> be > >>> done from rxtx other than trying recompiling on the trouble platforms > >>> (Its > >>> fixed things like this before). > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From moritz.gmelin at gmx.de Fri Jun 27 00:54:37 2003 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri, 27 Jun 2003 08:54:37 +0200 Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: Message-ID: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Sorry, no Dump. But ist was rxtx 2.1-7pre16 M. Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > Dang Moritz. You've 'got me in a bad spot' :) > > It is crashing on one machine and working on basically an identical > machine? This was rxtx 2.1-7pre16? > > Could you find anything different? Maybe he somehow used msft's jre? > Maybe the port configuration was different? Anything? > > Do you have a stack dump? > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >> Well, >> >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while >> the other didn't. I had to move the stuff back to suns comm-libs for >> the thing to be productive. It works with no problems there. >> >> M. >> >> >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent >> Jarvi: >> >>> >>> Dang.. XP eliminates 80% of the code involved (lock files). It was >>> testRead() that showed in the trace? But w32 is adding a POSIX like >>> layer... >>> >>> I wouldnt say the problems are the same yet. This is interesting >>> though. >>> I can suggest XP sp1 is tested even more than Linux by some. Well >>> that >>> may be an understatment. >>> >>> Was this rxtx 2.1? We have hundreds of hours of testing on those >>> pre16 >>> binaries. There is a known issue that can show up after 3+ hours of >>> intense testing on w32-nt types we are looking at but this would be >>> new. >>> >>> I dont think production systems on nice companies helping rxtx behind >>> the >>> scenes have moved to the 1.4 jre though things are being worked out. >>> I >>> tried to suggest not using 1.4 for this reason when the issue first >>> popped >>> up. >>> >>> I'm not sure what is going on yet. Lets start gathering the evidence >>> so >>> it can be reproduced. w32xp with which rxtx and which jre? >>> >>> We need to know how to reproduce the problem in Linux too. As far >>> as I >>> can tell that is still a glibc issue. >>> >>> This list is the only place I've heard of this problem. Not that >>> that >>> should be a shock. The use will vary wildly here. >>> >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: >>> >>>> Hi you both, >>>> >>>> since the same trouble appears in Windows (XP)-Environments too. Can >>>> it >>>> still be a glibc Problem ? >>>> I had no trouble myself with my XP-Box in the office. But a customer >>>> of >>>> mine had nothing but crashes on his. although we both hat XP-SP1 >>>> installed. I belive I had no Problems on either Linux or MacOS X. >>>> >>>> M. >>>> >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent >>>> Jarvi: >>>> >>>>> >>>>> >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: >>>>>>> >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think >>>>>>>> it >>>>>>>> worked >>>>>>>> with previous version of rxtx well. But I need to set MARK and >>>>>>>> SPACE >>>>>>>> parity in my application (previous version I used didn't >>>>>>>> supported >>>>>>>> it). >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But >>>>>>>> this >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I >>>>>>>> need >>>>>>>> to fix >>>>>>>> this very soon, otherwise my boss kill me :) >>>>>>>> >>>>>>> >>>>>>> I've just added a couple println's around the port enumeration in >>>>>>> the >>>>>>> example. testRead() is used during enumeration. >>>>>>> >>>>>>> + System.out.println("Enumerating ports"); >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); >>>>>>> + System.out.println("Enumerated ports"); >>>>>>> >>>>>>> >>>>>>> java SimpleRead >>>>>>> Enumerating ports >>>>>>> Devel Library >>>>>>> ========================================= >>>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>>> Enumerated ports >>>>>>> /dev/ttyS0 >>>>>>> Found port: /dev/ttyS0 >>>>>>> /dev/ttyS1 >>>>>>> ... waiting for input. >>>>>>> >>>>>>> There is nothing connected to the port, but that should not >>>>>>> matter >>>>>>> in this >>>>>>> case. >>>>>>> >>>>>>> This is a redhat 8.0 system: >>>>>>> >>>>>>> glibc-2.2.93-5 >>>>>>> kernel 2.4.18-14 >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) >>>>>>> rxtx-2.1-7pre16 default configure options. >>>>>>> >>>>>>> This also happens to be the system the binaries offered for pre16 >>>>>>> are >>>>>>> built on. >>>>>>> >>>>>>> testRead() should not be causing sig11's (memory corruption). >>>>>>> >>>>>>> I guess my questions are >>>>>>> >>>>>>> 1) What are the glibc versions that work and don't work for >>>>>>> you? >>>>>>> 2) Are you building rxtx on each system? If not, does that >>>>>>> help? >>>>>>> >>>>>>> If I had to guess, I suspect a glibc related glitch. >>>>>>> >>>>>>> >>>>>> >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun >>>>>> has >>>>>> bundled it with a bunch of 'stuff.' >>>>>> >>>>>> This is the same machine mentioned above. >>>>>> >>>>>> [] $ java -version && java SimpleRead >>>>>> java version "1.4.2" >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) >>>>>> Enumerating ports >>>>>> Devel Library >>>>>> ========================================= >>>>>> Native lib Version = RXTX-2.1-7pre16 >>>>>> Java lib Version = RXTX-2.1-7pre16 >>>>>> Enumerated ports >>>>>> /dev/ttyS0 >>>>>> Found port: /dev/ttyS0 >>>>>> /dev/ttyS1 >>>>>> >>>>> >>>>> [] $ java -version && java SimpleRead >>>>> java version "1.4.1_02" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> 1.4.1_02-b06) >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) >>>>> Enumerating ports >>>>> Devel Library >>>>> ========================================= >>>>> Native lib Version = RXTX-2.1-7pre16 >>>>> Java lib Version = RXTX-2.1-7pre16 >>>>> Enumerated ports >>>>> /dev/ttyS0 >>>>> Found port: /dev/ttyS0 >>>>> /dev/ttyS1 >>>>> >>>>> >>>>> So that is 3 data points of 1.4 that are known to work including >>>>> the >>>>> version you tried. I would strongly suspect this is a glibc issue. >>>>> >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for >>>>> patches >>>>> to filter into the distros that dont work. I seriously doubt much >>>>> can >>>>> be >>>>> done from rxtx other than trying recompiling on the trouble >>>>> platforms >>>>> (Its >>>>> fixed things like this before). >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at linuxgrrls.org >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at linuxgrrls.org >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at linuxgrrls.org >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at linuxgrrls.org >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Fri Jun 27 01:08:16 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 27 Jun 2003 08:08:16 +0100 (BST) Subject: [Rxtx] Crash in 1.4.1_02 In-Reply-To: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> References: <37DDF50A-A86C-11D7-8040-000393719396@gmx.de> Message-ID: I'd suggest this is not related at all to the linux issue. I don't doubt Moritz saw something but with no stack dump it could be anything. I'd like a chance to see what that was but I guess we will have to wait. There is a significant amount of code added for w32 support. Its mostly worked out but then again this is why we have pre16 and not a final release. I sure would like a shot at that bug if it was reproducable. On Fri, 27 Jun 2003, Moritz Gmelin wrote: > Sorry, no Dump. But ist was rxtx 2.1-7pre16 > > M. > > Am Freitag, 27.06.03, um 08:31 Uhr (Europe/Berlin) schrieb Trent Jarvi: > > > > > Dang Moritz. You've 'got me in a bad spot' :) > > > > It is crashing on one machine and working on basically an identical > > machine? This was rxtx 2.1-7pre16? > > > > Could you find anything different? Maybe he somehow used msft's jre? > > Maybe the port configuration was different? Anything? > > > > Do you have a stack dump? > > > > On Fri, 27 Jun 2003, Moritz Gmelin wrote: > > > >> Well, > >> > >> it was XP-SP1 with JDK1.4.1_02 on both machines. But one crashed while > >> the other didn't. I had to move the stuff back to suns comm-libs for > >> the thing to be productive. It works with no problems there. > >> > >> M. > >> > >> > >> Am Freitag, 27.06.03, um 07:21 Uhr (Europe/Berlin) schrieb Trent > >> Jarvi: > >> > >>> > >>> Dang.. XP eliminates 80% of the code involved (lock files). It was > >>> testRead() that showed in the trace? But w32 is adding a POSIX like > >>> layer... > >>> > >>> I wouldnt say the problems are the same yet. This is interesting > >>> though. > >>> I can suggest XP sp1 is tested even more than Linux by some. Well > >>> that > >>> may be an understatment. > >>> > >>> Was this rxtx 2.1? We have hundreds of hours of testing on those > >>> pre16 > >>> binaries. There is a known issue that can show up after 3+ hours of > >>> intense testing on w32-nt types we are looking at but this would be > >>> new. > >>> > >>> I dont think production systems on nice companies helping rxtx behind > >>> the > >>> scenes have moved to the 1.4 jre though things are being worked out. > >>> I > >>> tried to suggest not using 1.4 for this reason when the issue first > >>> popped > >>> up. > >>> > >>> I'm not sure what is going on yet. Lets start gathering the evidence > >>> so > >>> it can be reproduced. w32xp with which rxtx and which jre? > >>> > >>> We need to know how to reproduce the problem in Linux too. As far > >>> as I > >>> can tell that is still a glibc issue. > >>> > >>> This list is the only place I've heard of this problem. Not that > >>> that > >>> should be a shock. The use will vary wildly here. > >>> > >>> On Fri, 27 Jun 2003, Moritz Gmelin wrote: > >>> > >>>> Hi you both, > >>>> > >>>> since the same trouble appears in Windows (XP)-Environments too. Can > >>>> it > >>>> still be a glibc Problem ? > >>>> I had no trouble myself with my XP-Box in the office. But a customer > >>>> of > >>>> mine had nothing but crashes on his. although we both hat XP-SP1 > >>>> installed. I belive I had no Problems on either Linux or MacOS X. > >>>> > >>>> M. > >>>> > >>>> Am Freitag, 27.06.03, um 03:49 Uhr (Europe/Berlin) schrieb Trent > >>>> Jarvi: > >>>> > >>>>> > >>>>> > >>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 27 Jun 2003, Trent Jarvi wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, 26 Jun 2003, Robert Smol wrote: > >>>>>>> > >>>>>>>> Hi, I have same problem. I am using sun-jd2k-1.4.1.02. I think > >>>>>>>> it > >>>>>>>> worked > >>>>>>>> with previous version of rxtx well. But I need to set MARK and > >>>>>>>> SPACE > >>>>>>>> parity in my application (previous version I used didn't > >>>>>>>> supported > >>>>>>>> it). > >>>>>>>> When started with rxtx-2.1.7-pre16 it crash exatly the same. But > >>>>>>>> this > >>>>>>>> happens on Debian, my gentooBox works well. Can this help? I > >>>>>>>> need > >>>>>>>> to fix > >>>>>>>> this very soon, otherwise my boss kill me :) > >>>>>>>> > >>>>>>> > >>>>>>> I've just added a couple println's around the port enumeration in > >>>>>>> the > >>>>>>> example. testRead() is used during enumeration. > >>>>>>> > >>>>>>> + System.out.println("Enumerating ports"); > >>>>>>> portList = CommPortIdentifier.getPortIdentifiers(); > >>>>>>> + System.out.println("Enumerated ports"); > >>>>>>> > >>>>>>> > >>>>>>> java SimpleRead > >>>>>>> Enumerating ports > >>>>>>> Devel Library > >>>>>>> ========================================= > >>>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>>> Enumerated ports > >>>>>>> /dev/ttyS0 > >>>>>>> Found port: /dev/ttyS0 > >>>>>>> /dev/ttyS1 > >>>>>>> ... waiting for input. > >>>>>>> > >>>>>>> There is nothing connected to the port, but that should not > >>>>>>> matter > >>>>>>> in this > >>>>>>> case. > >>>>>>> > >>>>>>> This is a redhat 8.0 system: > >>>>>>> > >>>>>>> glibc-2.2.93-5 > >>>>>>> kernel 2.4.18-14 > >>>>>>> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) > >>>>>>> rxtx-2.1-7pre16 default configure options. > >>>>>>> > >>>>>>> This also happens to be the system the binaries offered for pre16 > >>>>>>> are > >>>>>>> built on. > >>>>>>> > >>>>>>> testRead() should not be causing sig11's (memory corruption). > >>>>>>> > >>>>>>> I guess my questions are > >>>>>>> > >>>>>>> 1) What are the glibc versions that work and don't work for > >>>>>>> you? > >>>>>>> 2) Are you building rxtx on each system? If not, does that > >>>>>>> help? > >>>>>>> > >>>>>>> If I had to guess, I suspect a glibc related glitch. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One more datapoint. I'll check 1.4.1_02 when its downloaded. Sun > >>>>>> has > >>>>>> bundled it with a bunch of 'stuff.' > >>>>>> > >>>>>> This is the same machine mentioned above. > >>>>>> > >>>>>> [] $ java -version && java SimpleRead > >>>>>> java version "1.4.2" > >>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) > >>>>>> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) > >>>>>> Enumerating ports > >>>>>> Devel Library > >>>>>> ========================================= > >>>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>>> Enumerated ports > >>>>>> /dev/ttyS0 > >>>>>> Found port: /dev/ttyS0 > >>>>>> /dev/ttyS1 > >>>>>> > >>>>> > >>>>> [] $ java -version && java SimpleRead > >>>>> java version "1.4.1_02" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build > >>>>> 1.4.1_02-b06) > >>>>> Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) > >>>>> Enumerating ports > >>>>> Devel Library > >>>>> ========================================= > >>>>> Native lib Version = RXTX-2.1-7pre16 > >>>>> Java lib Version = RXTX-2.1-7pre16 > >>>>> Enumerated ports > >>>>> /dev/ttyS0 > >>>>> Found port: /dev/ttyS0 > >>>>> /dev/ttyS1 > >>>>> > >>>>> > >>>>> So that is 3 data points of 1.4 that are known to work including > >>>>> the > >>>>> version you tried. I would strongly suspect this is a glibc issue. > >>>>> > >>>>> You could drop to jdk 1.3, upgrade glibc to known good or wait for > >>>>> patches > >>>>> to filter into the distros that dont work. I seriously doubt much > >>>>> can > >>>>> be > >>>>> done from rxtx other than trying recompiling on the trouble > >>>>> platforms > >>>>> (Its > >>>>> fixed things like this before). > >>>>> _______________________________________________ > >>>>> Rxtx mailing list > >>>>> Rxtx at linuxgrrls.org > >>>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rxtx mailing list > >>>> Rxtx at linuxgrrls.org > >>>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at linuxgrrls.org > >>> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at linuxgrrls.org > >> http://hex.linuxgrrls.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From michael at dunlops.com Sun Jun 1 12:01:53 2003 From: michael at dunlops.com (Michael Andreasen) Date: Sun, 01 Jun 2003 19:01:53 +0100 Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <20030530190310.92561.qmail@web14204.mail.yahoo.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> Message-ID: <3EDA3F91.8070809@dunlops.com> I am using rxtx with the standard javax.comm.* packages, however I'm getting a problem. I have downloaded the latest 2.0 files (the ones for java.comm, right?) from here; http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ I was getting strange "class not found" exceptions, so I disassembled the class files in the jcl.jar archive. The problem appear to be that these class files have not been compiled with imports for javax.comm, so it is trying to find CommDriver in gnu.io instead of javax.comm. Obviously, this is not right for the javax.comm implementation. Cheers, Michael. From redirectz at yahoo.es Tue Jun 3 05:48:44 2003 From: redirectz at yahoo.es (redirectz) Date: 03 Jun 2003 06:48:44 -0500 Subject: [Rxtx] problem using parallel port Message-ID: <1054640935.1138.5.camel@localhost.localdomain> Hi friends... Please. I want to use my parrallel port using java, I'm using rxtx 2.6-1, but I have a problem with send/receive data using parallel port (i'm forgetting something)... I made two classes, one to send and the other to receive... I hope don't look like a folish if paste my code but i'm desperate CLASS FOR RECEIVE DATA -- BEGIN OF CLASS---------------------------------------------- package miParalelo; import java.io.*; import java.util.*; import gnu.io.*; public class pReceptor implements Runnable { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; Thread readThread; public pReceptor() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("myReader", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} readThread = new Thread(this); readThread.start(); } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pReceptor(); } } public void run() { boolean salida = false; byte[] laSalida = new byte[100]; while( !salida ) { try { while (inputStream.available() > 0) { int leidos = inputStream.read( laSalida ); } System.out.println(new String(laSalida) ); salida = true; } catch (IOException e) {} try { Thread.sleep(1000); }catch (InterruptedException e) {} } } } -- END OF CLASS---------------------------------------- And now my class to send data... the more rare thing is that when run this class -> it never finish CLASS FOR SEND DATA -- BEGIN OF CLASS---------------------------------------------- public class pEnviador { static CommPortIdentifier portId; static Enumeration portList; ParallelPort parallelPort; InputStream inputStream; OutputStream outputStream; static String myMessage="pepo"; public pEnviador() { System.out.println("it is alive"); try { parallelPort = (ParallelPort) portId.open("MyApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); outputStream = parallelPort.getOutputStream(); } catch (IOException e) {} try { //outputStream.write( myMessage.getBytes() ); byte myData = 1; outputStream.write( myData ); } catch (IOException e) {} } public static void main(String[] args) { portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) if (portId.getName().equals("/dev/lp0")) new pEnviador(); } System.out.println("I never see this line"); } } -- END OFCLASS---------------------------------------- From rwelty at averillpark.net Tue Jun 3 06:37:49 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: i built RXTX 2.1.6 a couple of months ago and had all kinds of ./configure and makefile glitches, which i worked through by hand editing the makefile. now i need to recompile and reinstall (upgraded to jdk 1.4.1_02 from 1.4.1_01), and i'm revisiting those issues. what is the proper setup to get this to go correctly? what i have right now is as follows, which works for most things but not for building RXTX: JDK_HOME=/usr/java/j2sdk1.4.1_02 JAVA_HOME=${JDK_HOME}/jre JAVA_LOCAL=/usr/local/java CLASSPATH=${JAVA_HOME}/lib/rt.jar:${JAVA_LOCAL}/lib/pgjdbc2.jar LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${JAVA_HOME}/lib:${JAVA_LOCAL}/lib export JDK_HOME JAVA_HOME CLASSPATH LD_LIBRARY_PATH JAVA_LOCAL it appears things are crossed between what is in $JDK_HOME and what is in $JAVA_HOME and i've yet to find an arrangement that works well. thanks, richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From jj_public at yahoo.ca Tue Jun 3 07:14:02 2003 From: jj_public at yahoo.ca (JJ) Date: Tue, 3 Jun 2003 10:44:02 -0230 Subject: [Rxtx] problem using parallel port In-Reply-To: <1054640935.1138.5.camel@localhost.localdomain> References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: <200306031044.02068.jj_public@yahoo.ca> On June 3, 2003 9:18 am, redirectz wrote: > Hi friends... > And now my class to send data... the more rare thing is that when run > this class -> it never finish Make sure you close your port before ending the program. If you don't close it, the program will not terminate. Of course, you can always force it to terminate with System.exit(0); but if you close everything down, you shouldn't have to. Hope this helps! From rwelty at averillpark.net Tue Jun 3 08:12:24 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty wrote: > JDK_HOME=/usr/java/j2sdk1.4.1_02 > JAVA_HOME=${JDK_HOME}/jre > JAVA_LOCAL=/usr/local/java some further commentary based on my current experiences: RXTX seems to want to install in the jre lib directories. this turns out to be bad when you do, for example, an rpm based upgrade of Sun's JDK, as the rpm upgrade process cheerfully nukes the previous lib directory and gets rid of all the files RXTX installs there. i don't know if there's a standard place to put local java files outside the jdk/jre tree, i normally set up /usr/local/java (per the enviroment variable setups i give above.) richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:31:37 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 10:12:24 -0400 (EDT) Richard Welty wrote: > On Tue, 3 Jun 2003 08:37:49 -0400 (EDT) Richard Welty > wrote: > > JDK_HOME=/usr/java/j2sdk1.4.1_02 > > JAVA_HOME=${JDK_HOME}/jre > > JAVA_LOCAL=/usr/local/java > > some further commentary based on my current experiences: > > RXTX seems to want to install in the jre lib directories. this turns out > to > be bad when you do, for example, an rpm based upgrade of Sun's JDK, as > the > rpm upgrade process cheerfully nukes the previous lib directory and gets > rid of all the files RXTX installs there. in further attempting to hack through this, i decided to play with the make file again. the following changes allowed javac and the like to be found (with a but that comes later in this email message): [root at skipper rxtx-2.1-6]# diff Makefile Makefile.generated 116,119c116,119 < JAR = $(JSDKPATH)/bin/jar < JAVAC = $(JSDKPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O < JAVADOC = $(JSDKPATH)/bin/javadoc < JAVAH = $(JSDKPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni --- > JAR = $(JPATH)/bin/jar > JAVAC = $(JPATH)/bin/javac -classpath $(CLASSPATH) -d $(TOP)/ -O > JAVADOC = $(JPATH)/bin/javadoc > JAVAH = $(JPATH)/bin/javah -classpath $(CLASSPATH) -d $(DEST) -jni 122c122 < JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/include --- > JAVAINCLUDEDIR = /usr/java/j2sdk1.4.1_02/jre/include 131d130 < JSDKPATH = /usr/java/j2sdk1.4.1_02/ however, now there's a problem with the include directory in j2sdk 1.4.1_02: In file included from gnu_io_RXTXPort.h:2, from /tools/rxtx/rxtx-2.1-6/src/SerialImp.c:23: /usr/java/j2sdk1.4.1_02/include/jni.h:27:20: jni_md.h: No such file or directory it turns out that jni_md.h is in the subdirectory include/linux in this particular distribution. i'm going to continue slashing and burning my way through this, probably by symlinking jni_md.h in one level up. but please tell me there's a better solution. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From rwelty at averillpark.net Tue Jun 3 09:49:19 2003 From: rwelty at averillpark.net (Richard Welty) Date: Tue, 3 Jun 2003 11:49:19 -0400 (EDT) Subject: [Rxtx] environment variable setup for RXTX build In-Reply-To: References: <1054640935.1138.5.camel@localhost.localdomain> Message-ID: On Tue, 3 Jun 2003 11:31:37 -0400 (EDT) Richard Welty wrote: > it turns out that jni_md.h is in the subdirectory include/linux in this > particular distribution. i'm going to continue slashing and burning my > way > through this, probably by symlinking jni_md.h in one level up. ok, that change got it to compile, now for the install glitch. from the makefile: RXTX_PATH = $(JPATH)/jre/lib/$(OS_ARCH) now the way things set up, JPATH already has jre/ in it, so this gets doubled and points at a non-existent directory. hand editing jre/ out of RXTX_PATH got it to finish. i subsequently moved the rxtx files over to /usr/local/java/lib so future java upgrades won't remove them automagically, and now it seems to be working ok. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security From chris.avis at baesystems.com Wed Jun 4 23:57:54 2003 From: chris.avis at baesystems.com (AVIS, Chris) Date: Thu, 5 Jun 2003 15:27:54 +0930 Subject: [Rxtx] HPUX 100% CPU Utilisation Message-ID: <41842F7B366BD611A8E100D0B7910EC20ED8B3@KENTFP1> We have recently moved a Serial application from a Windows 2000 box to our HPUX Cluster. We have used the new HPUX Java Communications API which is the HP build of RXTX 2.0-5. We have experienced a problem with the CPU utilisation running at 100% under HPUX. We have not experienced this problem under Windows 2000, and the problem exists even if no communications is occuring over the serial link. We have run Java with the -Xprof option and it appears to be spending more than 99.5% of the time in the native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on other HPUX systems? Is there a solution to this problem? We have tried building both RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the HP build. The hardware configuration of our HPUX cluster is a two rp2470 node system, each with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java 1.4.1_01 downloaded from HP. Regards Chris Chris Avis WAPS CADCOM Project <<...OLE_Obj...>> PO Box 1755 Midland WA 6936 Phone 9374 8617 Fax 9374 8666 Mobile 0408 244 734 Email chris.avis at baesystems.com From allan at data-house.com Tue Jun 3 09:04:14 2003 From: allan at data-house.com (K. Allan Wilson) Date: 03 Jun 2003 10:04:14 -0500 Subject: [Rxtx] lock file question Message-ID: <1054652655.2035.6.camel@allanxp> Hopefully this is an easy question. I am getting the following warning message: RXTX Warning: Removing stale lock file. Although this warning comes up on the display it does not cause a problem. I do not want the user to be able to see this error message so I need to either fix the problem or supress error messages from going to standard out. Any idea? Allan Wilson From jj_public at yahoo.ca Sat Jun 7 08:43:05 2003 From: jj_public at yahoo.ca (JJ) Date: Sat, 7 Jun 2003 12:13:05 -0230 Subject: [Rxtx] lock file question References: <1054652655.2035.6.camel@allanxp> Message-ID: <000801c32d03$1b897190$0f00a8c0@taz> In Linux, if you don't need any output to appear you can pipe it to a file program >> filename.txt 2>&1 or alternatively, you can pipe it to /dev/null ----- Original Message ----- From: "K. Allan Wilson" To: Sent: Tuesday, June 03, 2003 12:34 PM Subject: [Rxtx] lock file question > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 09:21:08 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 16:21:08 +0100 (BST) Subject: [Rxtx] lock file question In-Reply-To: <1054652655.2035.6.camel@allanxp> References: <1054652655.2035.6.camel@allanxp> Message-ID: The error message is informative and will not be removed from rxtx. The previous application (possibly yours) did not remove the lock file before exiting. I suspect if you close the port before exiting the message will go away. Closing the port will remove your lock file. There is a (very bad) option in rxtx configure to remove lock file support on Unix if you do not like the messages. It is my understanding that SUSE has recently moved its lock file location. This suggests that the FHS has suggested a new location. I've not had time to review SUSE's action but rxtx will continue to support the FHS and cause problems on non compliant systems unless a more suitable standard is found. http://www.pathname.com/fhs/2.2/fhs-5.9.html On Tue, 3 Jun 2003, K. Allan Wilson wrote: > Hopefully this is an easy question. I am getting the following warning > message: > > RXTX Warning: Removing stale lock file. > > Although this warning comes up on the display it does not cause a > problem. I do not want the user to be able to see this error message so > I need to either fix the problem or supress error messages from going to > standard out. Any idea? > > Allan Wilson > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sat Jun 7 10:44:11 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Sat, 7 Jun 2003 17:44:11 +0100 (BST) Subject: [Rxtx] jcl.jar import for javax.comm missing? In-Reply-To: <3EDA3F91.8070809@dunlops.com> References: <20030530190310.92561.qmail@web14204.mail.yahoo.com> <3EDA3F91.8070809@dunlops.com> Message-ID: This would be a mistake if true. For most uses, rxtx-2.0-5 should be ok. I'll be releasing 2.0 and 2.1 this comming week. rxtx 2.0 is essentially a subset of 2.1 with packages modified to work with Sun's commapi and a small license change for HP. Most testing happens with 2.1 and then the packages are modified for 2.0. It sounds like I missed something in that prerelease. On Sun, 1 Jun 2003, Michael Andreasen wrote: > I am using rxtx with the standard javax.comm.* packages, however I'm > getting a problem. I have downloaded the latest 2.0 files (the ones for > java.comm, right?) from here; > > http://www.frii.com/~jarvi/rxtx//download/prerelease/2.0/ > > I was getting strange "class not found" exceptions, so I disassembled > the class files in the jcl.jar archive. The problem appear to be that > these class files have not been compiled with imports for javax.comm, so > it is trying to find CommDriver in gnu.io instead of javax.comm. > Obviously, this is not right for the javax.comm implementation. > > Cheers, Michael. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From taj at linuxgrrls.org Sun Jun 8 23:18:44 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 06:18:44 +0100 (BST) Subject: [Rxtx] HPUX 100% CPU Utilisation In-Reply-To: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: Hi Chris, Let's hope we can get ssh access to a box. HP owes rxtx big time for making a LGPL modification for them in rxtx 2.0 free of charge and hassle. Don't be afraid to remind them of that. I could have forced them to pay for an HP box at the time but just did the right thing as they should now. It is not easy to know whats going on. The one thing I may suggest is replacing the usleep with a sleep. The eventLoop should be fairly intuitive without digging into the called functions below it. Just try to put the brakes on it with some sleeps. If you go beyond 10 ms bad things will start to happen but 1 ms should make the problem all but go away. Maybe that select() is not doing what I expect? Are you sitting with unread data? If this is really critical you could always use a pc and tcp/ip to get the data where it needs to go... I've cc'd Cathrine who did the original HP-UX port (great gal). I've also cc'd Awais who was involved in the more official HP/rxtx 2.0.5 port/license modifications. Cathrine's work was what encouraged me to help HP with the license issues. Thats about all I can think of to help you at this point. Feel free to forward this email to your HP contacts also. On Mon, 9 Jun 2003, AVIS, Chris wrote: > Trent, > > hopefully you have read my previous email to HP and they will do the > decent thing and cough up a machine for you. > > Looks like we may have to go down the "blind" path for a while. I did > a grep on the code and there are a few occurences of usleep in SerialImp.c > but none appear to be compiled out under any non Sun architecture including > HP. Any suggestions? > > Regards > Chris > > Chris Avis > WAPS CADCOM Project > > PO Box 1755 Midland WA 6936 > Phone 9374 8617 > Fax 9374 8666 > > > > > -----Original Message----- > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > Sent: Saturday, 7 June 2003 23:16 > To: AVIS, Chris > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > Hi Chris: > > Is it possible that I could get access to this machine to see whats going > on? > > I can try helping in a blind remote fashion but the faster way will be to > try/test event loop modifications on HP. > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > compiled out on HP. Not having access to an HP box is the limiting factor > for HP development from this end. > > Trent Jarvi > Maintainer www.rxtx.org > taj at www.linux.org.uk > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > We have recently moved a Serial application from a Windows 2000 box to our > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > the HP build of RXTX 2.0-5. > > > > We have experienced a problem with the CPU utilisation running at 100% > under > > HPUX. We have not experienced this problem under Windows 2000, and the > > problem > > exists even if no communications is occuring over the serial link. We have > > run Java > > with the -Xprof option and it appears to be spending more than 99.5% of > the > > time in the > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen this behaviour on > > other > > HPUX systems? Is there a solution to this problem? We have tried building > > both > > RXTX 2.0-5 and 2.1-6 for ourselves with exactly the same behaviour as the > HP > > build. > > > > The hardware configuration of our HPUX cluster is a two rp2470 node > system, > > each > > with 2 CPUs and 3GB RAM per node running HPUX 11.0. We are running Java > > 1.4.1_01 > > downloaded from HP. > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > <<...OLE_Obj...>> > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > Mobile 0408 244 734 > > Email chris.avis at baesystems.com > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > > From rkannan at govpx.com Mon Jun 9 12:25:18 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:25:18 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX Message-ID: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK From ricardo.trindade at emation.pt Mon Jun 9 12:25:42 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Mon, 09 Jun 2003 19:25:42 +0100 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: what version of rxtx are you using ? if 1.x you need the -noverify jvm argument. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Raman Kannan Enviada: segunda-feira, 9 de Junho de 2003 19:25 Para: rxtx at linuxgrrls.org Assunto: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX java SimpleRead /dev/ttyS0 Found port: /dev/ttyS0 Exception in thread "main" java.lang.VerifyError: (class: gnu/io/RXTXPort$Serial OutputStream, method: flush signature: ()V) Illegal use of nonvirtual function c all at gnu.io.RXTXPort.(RXTXPort.java) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) at SimpleRead.(SimpleRead.java:93) at SimpleRead.main(SimpleRead.java:75) THank you -- RK _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://undine.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Mon Jun 9 12:34:41 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Mon, 9 Jun 2003 19:34:41 +0100 (BST) Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: I've seen this long ago but my memory is fuzzy here. I think java -noverify will deal with it. google will be better than my fuzzy memory but maybe someone else could help. On Mon, 9 Jun 2003, Raman Kannan wrote: > java SimpleRead /dev/ttyS0 > Found port: /dev/ttyS0 > Exception in thread "main" java.lang.VerifyError: (class: > gnu/io/RXTXPort$Serial > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > function c > all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > > THank you > -- > RK > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > From rkannan at govpx.com Mon Jun 9 12:43:11 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:11 -0400 Subject: [Rxtx] need help -- trouble reading from serial port in i386 running gnu linux using RXTX In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609143848.01aa52b0@mail1.govpx.com> That was it. I did read about this option and when I tried jvm complained with no verify being unsupported. But the problem was somethign else then (uucp permissions and the exact location of jars and .so from java.library.path. wrote a small java class to find out the path and cped the .so there import java.util.*; class testpath { static public void main (String s[]) { Properties p = System.getProperties(); System.out.println ( p.getProperty("java.library.path")); } } then the app is now running only as root...otherwise it does not run. In solving these I forgot about the noverify and out of desperation I posted... thank you again -- rk At 07:25 PM 6/9/2003 +0100, you wrote: >what version of rxtx are you using ? if 1.x you need the -noverify jvm >argument. > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Raman Kannan >Enviada: segunda-feira, 9 de Junho de 2003 19:25 >Para: rxtx at linuxgrrls.org >Assunto: [Rxtx] need help -- trouble reading from serial port in i386 >running gnu linux using RXTX > > >java SimpleRead /dev/ttyS0 >Found port: /dev/ttyS0 >Exception in thread "main" java.lang.VerifyError: (class: >gnu/io/RXTXPort$Serial >OutputStream, method: flush signature: ()V) Illegal use of nonvirtual >function c >all > at gnu.io.RXTXPort.(RXTXPort.java) > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > at SimpleRead.(SimpleRead.java:93) > at SimpleRead.main(SimpleRead.java:75) > >THank you >-- >RK > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From rkannan at govpx.com Mon Jun 9 12:43:51 2003 From: rkannan at govpx.com (Raman Kannan) Date: Mon, 09 Jun 2003 14:43:51 -0400 Subject: [Rxtx] -noverify does it...thanks very much In-Reply-To: References: <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> <4.3.2.7.2.20030609142333.01a42d58@mail1.govpx.com> Message-ID: <4.3.2.7.2.20030609144334.01a70df8@mail1.govpx.com> At 07:34 PM 6/9/2003 +0100, you wrote: >I've seen this long ago but my memory is fuzzy here. > >I think java -noverify will deal with it. > >google will be better than my fuzzy memory but maybe someone else could >help. > >On Mon, 9 Jun 2003, Raman Kannan wrote: > > > java SimpleRead /dev/ttyS0 > > Found port: /dev/ttyS0 > > Exception in thread "main" java.lang.VerifyError: (class: > > gnu/io/RXTXPort$Serial > > OutputStream, method: flush signature: ()V) Illegal use of nonvirtual > > function c > > all > > at gnu.io.RXTXPort.(RXTXPort.java) > > at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java) > > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:634) > > at SimpleRead.(SimpleRead.java:93) > > at SimpleRead.main(SimpleRead.java:75) > > > > THank you > > -- > > RK > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://undine.linuxgrrls.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at linuxgrrls.org >http://undine.linuxgrrls.org/mailman/listinfo/rxtx From awais at cup.hp.com Mon Jun 9 22:02:12 2003 From: awais at cup.hp.com (Awais Sheikh) Date: Mon, 9 Jun 2003 21:02:12 -0700 Subject: [Rxtx] HPUX 100% CPU Utilisation References: <41842F7B366BD611A8E100D0B7910EC20ED8C9@KENTFP1> Message-ID: <041101c32f05$1287fdb0$c35ef40f@am710222> Hello Chris/Trent, We are not actively involved with activities on RXTX and it's mailing list. To get quick response from HP, It's important to send requests through your HP support contact. For issues related to HP Java Runtime or Java Tools, one may also consider sending email addressing gojava at cup.hp.com Sometime about a year back we invested some effort to make RXTX based native library to work on HPUX. It was based on 2.0.5. It available for reference only. For all latest updates http://www.rxtx.org is the source. Please also read statement of support for the Comm API at URL http://www.hp.com/products1/unix/java/com_api/support/index.html I am not sure where/what could be the problem. Is it possible you could provide us any test case. If not can you please try running your application using option -Xeprof. This should generate an output file. Can we get that eprof file. You may not have to but, you might also wanna consider viewing this eprof file using HPjmeter (performance analysis tool ) accessible from: http://www.hpjmeter.com http://www.hp.com/products1/unix/java/hpjmeter/index.html Regards, Awais ----- Original Message ----- From: "Trent Jarvi" To: "AVIS, Chris" Cc: ; ; "LUONG, Minh-Tuan" ; Sent: Sunday, June 08, 2003 10:18 PM Subject: RE: [Rxtx] HPUX 100% CPU Utilisation > > Hi Chris, > > Let's hope we can get ssh access to a box. HP owes rxtx big time for > making a LGPL modification for them in rxtx 2.0 free of charge and hassle. > Don't be afraid to remind them of that. I could have forced them to pay > for an HP box at the time but just did the right thing as they should now. > > It is not easy to know whats going on. The one thing I may suggest is > replacing the usleep with a sleep. The eventLoop should be fairly > intuitive without digging into the called functions below it. Just try to > put the brakes on it with some sleeps. If you go beyond 10 ms bad things > will start to happen but 1 ms should make the problem all but go away. > > Maybe that select() is not doing what I expect? Are you sitting with > unread data? > > If this is really critical you could always use a pc and tcp/ip to > get the data where it needs to go... > > I've cc'd Cathrine who did the original HP-UX port (great gal). I've also > cc'd Awais who was involved in the more official HP/rxtx 2.0.5 > port/license modifications. > > Cathrine's work was what encouraged me to help HP with the license issues. > > Thats about all I can think of to help you at this point. Feel free to > forward this email to your HP contacts also. > > On Mon, 9 Jun 2003, AVIS, Chris wrote: > > > Trent, > > > > hopefully you have read my previous email to HP and they will do the > > decent thing and cough up a machine for you. > > > > Looks like we may have to go down the "blind" path for a while. I did > > a grep on the code and there are a few occurences of usleep in SerialImp.c > > but none appear to be compiled out under any non Sun architecture including > > HP. Any suggestions? > > > > Regards > > Chris > > > > Chris Avis > > WAPS CADCOM Project > > > > PO Box 1755 Midland WA 6936 > > Phone 9374 8617 > > Fax 9374 8666 > > > > > > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:taj at linuxgrrls.org] > > Sent: Saturday, 7 June 2003 23:16 > > To: AVIS, Chris > > Subject: Re: [Rxtx] HPUX 100% CPU Utilisation > > > > > > > > > > Hi Chris: > > > > Is it possible that I could get access to this machine to see whats going > > on? > > > > I can try helping in a blind remote fashion but the faster way will be to > > try/test event loop modifications on HP. > > > > I'm guessing a sleep (up to 10 ms would be typically OK) is just being > > compiled out on HP. Not having access to an HP box is the limiting factor > > for HP development from this end. > > > > Trent Jarvi > > Maintainer www.rxtx.org > > taj at www.linux.org.uk > > > > On Thu, 5 Jun 2003, AVIS, Chris wrote: > > > > > We have recently moved a Serial application from a Windows 2000 box to our > > > HPUX Cluster. We have used the new HPUX Java Communications API which is > > > the HP build of RXTX 2.0-5. > > > > > > We have experienced a problem with the CPU utilisation running at 100% > > under > > > HPUX. We have not experienced this problem under Windows 2000, and the > > > problem > > > exists even if no communications is occuring over the serial link. We have > > > run Java > > > with the -Xprof option and it appears to be spending more than 99.5% of > > the > > > time in the > > > native method gnu.io.RXTXPort.eventLoop. Has anyone seen